Why does your client need/want to read the token?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 20, 2015, at 9:34 AM, William Denniss wdenn...@google.com wrote:
Even if the primary target is the protected resource, is there a reason to
exclude use by clients?
Hi all,
for those who are attending the IETF#93 meeting in Prague I thought it
would be nice to get together for a face-to-face discussion before we
have our official working group meeting.
I therefore suggest to meet at **11:30** (after the COSE meeting) at the
Hilton hotel registration desk
Apologies, I did not mean read, but introspect the token.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 20, 2015, at 9:38 AM, Phil Hunt phil.h...@oracle.com wrote:
Why does your client need/want to read the token?
Phil
@independentid
www.independentid.com
In OAuth, the token is opaque to the client. Clients in general don’t need to
know the kinds of token information that’s returned from the introspection
endpoint. Clients already get information about scopes and expiration from the
token endpoint, what else do they need? If they need more
Hi,
I've always thought OAuth2 clients are out of the picture here, except
that the resource server needs to introspect a client's token and it
(the resource server) needs to authenticate to the introspection endpoint.
Letting the actual OAuth2 clients (confidential or public ones) also
Any good access token implementation should make such scanning totally
infeasible (via sufficient entropy in the token, if it's a reference, or
cryptographic protections, if it's self contained).
Authentication/authorization at the introspection endpoint, in my view
anyway, is more about privacy
Okay, if the intent is for this endpoint to be used by the resource server,
this all makes sense. I was under the impression that it could also be used
by clients to verify if the token is valid. Is there some other spec I
could look at that is intended to be used by clients to verify if a token
You get the AT validity period with the token expires_in. The Refresh token
doesn't expire.
A token could be revoked in less than the expiry time but you discover that by
using it.
If you get a error on the API using the AT then you make the user re authorize
you via the Authorization
I'm looking for a way to check if an existing token is still valid. Imagine
a client is holding on to a token between user sessions, for example if
it's making API requests for the user on a cron job. When the user returns
to the site, I want to check if the token is still valid, and make them
If you want the resource owner/user then get a id_token from the token
endpoint. That saves another call to a introspection endpoint.
Sent from my iPhone
On Jul 20, 2015, at 7:49 PM, Aaron Parecki aa...@parecki.com wrote:
Okay, if the intent is for this endpoint to be used by the
10 matches
Mail list logo
