Okay, I understand more of the intent of this document now. I will say that
the first time I read it, it was not at all clear that it was not intended
for OAuth 2.0 clients to use this endpoint. It seems now that it is only
intended for internal servers to use, such as when a resource server is
Hi
Would there be any sense at all to have a new endpoint dedicated to
supporting public clients only for these clients be able to do the extra
validation which only public clients may need, etc, etc.
Or perhaps let the access token endpoint not only exchange grants but
also do some optional
Just use the token at your target API and see if it works. Your client’s going
to need to be able to get a new token if this one expires mid-session anyway,
so you’re not saving anything by doing an introspection request.
— Justin
On Jul 20, 2015, at 9:34 PM, Aaron Parecki aa...@parecki.com
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?
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
?)
Cheers,
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Aaron Parecki
Sent: Sunday, July 19, 2015 6:31 AM
To: OAuth WG
Subject: [OAUTH-WG] Token introspection for public clients?
The introspection draft
How are public clients supposed to authenticate if there is no secret?
Isn't fishing for valid tokens just as much of an issue at the resource
server? I don't see how having the introspection endpoint require client
authentication actually solves the fishing problem since attackers could
just
In the case of a “public client” using a token, the authorization is the token
that the resource server uses to call the introspection endpoint, along side
the token that it is introspecting. This is exactly how the UMA protocol works:
the resource server has a “Protection API Token” that it
Because the target isn’t the client, it’s the protected resource. We’re
re-using OAuth’s client credentialing mechanisms (optionally, you can use
whatever you deem necessary), but it’s not a client that’s doing it. That’s why
it was changed to a MUST — there may be public clients out there
I totally agree with that - and that’s how we gonna implement it in identity
server.
We are planning to introduce something called a “scope secret” - it’s like a
client secret but for resources.
—
cheers
Dominick Baier
On 20 Jul 2015 at 07:01:48, Justin Richer (jric...@mit.edu) wrote:
Public clients can use the token-based auth mechanism, can’t they? If you don’t
have some form of authentication on the introspection endpoint, you end up with
a way for people to anonymously and programmatically fish for valid token
values.
— Justin
On Jul 19, 2015, at 6:30 AM, Aaron
18 matches
Mail list logo
