Subject: [OAUTH-WG] Token introspection for public clients?

From: Aaron Parecki <[email-masked]>
Date: Sat, 18 Jul 2015 21:30:34 -0700

The introspection draft states that the introspection endpoint MUST require
authentication of clients. It mentions either client authentication
(id+secret) or a separate bearer token.

How are public clients expected to use the token introspection endpoint? I
didn't see a note in the document about that at all.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Mike Jones <[email-masked]>
Date: Sun, 19 Jul 2015 05:00:44 +0000

As a note for the upcoming Token Exchange discussion in Prague, I’ll note that this same question may apply there.  Specifically, can the party requesting the exchange be a public client?  (And does it have to be an OAuth client at all?)

                                                            Cheers,
                                                            -- Mike

From: OAuth [mailto:[email-masked]] 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 states that the introspection endpoint MUST require authentication of clients. It mentions either client authentication (id+secret) or a separate bearer token.

How are public clients expected to use the token introspection endpoint? I didn't see a note in the document about that at all.

----
Aaron Parecki
aaronparecki.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faaronparecki.com&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OLWwlvUWyXz2HZaGyASvAlZ9fEhJt6a7A3%2bdfdgUdUY%3d>
@aaronpk<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2faaronpk&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U7RXStYZ1HIL%2bTlM99%2fYW8W9RPw8bTgHgXcjuvyK0t0%3d>

---

From: Justin Richer <[email-masked]>
Date: Sun, 19 Jul 2015 07:04:50 +0200

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 Parecki <[email-masked]> wrote:
> 
> aaronparecki.com <http://aaronparecki.com/>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Sun, 19 Jul 2015 12:58:30 +0200

That is one of the place that using a POP mechanism may be useful.  If the client has established a key with the AS that issued the original token say via PKCE then,  then it may be possible to bind the token being exchanged to the party exchanging it even if the exchanger has no pre exchanged credentials with the token exchange endpoint.

In the ACDC proposal part of profiling the assertion exchange was to require that they be POP tokens using PKCE as the confirmation method.

I would like to think that the ACDC use case is something that can be addressed by the final token exchange spec.

In OAuth and Connect we have three entities that receive tokens.  
1, User agents:  code, token, id_token (any of them might be PoP using token binding) 
2, Clients:  code (pop via PKCE) Refresh tokens (pop via Token binding?),  access tokens (pop via the OAuth POP spec) , id_tokens (token binding via browser)  ,  jwt or other assertions (?)
3 Resource Server:  Access tokens ( these might be bound to the Audience of the token for exchange)

To the original question.   The client might use dynamic client registration,  or it might use PKCE.  

 In the PKCE case if the AT a POP token and the client uses it’s POP key to prove it it’s identity then it should be able to introspect the token.  
Though from a spec point of view there are admittedly still some gaps in doing that at the moment.

John B.

> On Jul 19, 2015, at 7:00 AM, Mike Jones <[email-masked]> wrote:
> 
> aaronparecki.com <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2faaronparecki.com&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OLWwlvUWyXz2HZaGyASvAlZ9fEhJt6a7A3%2bdfdgUdUY%3d>
> @aaronpk <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftwitter.com%2faaronpk&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf827a8f80a39419ba5e208d28ff2ce12%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U7RXStYZ1HIL%2bTlM99%2fYW8W9RPw8bTgHgXcjuvyK0t0%3d>
>

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 19 Jul 2015 17:59:16 +0000

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 fish against the resource server. In fact, if the resource server
queries the introspection endpoint to check if tokens are valid, then that
effectively gives an attacker a way to fish for tokens using the resource
server's credentials.

---
Aaron Parecki
http://aaronparecki.com

On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <[email-masked]> 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
>
> The introspection draft states that the introspection endpoint MUST
> require authentication of clients. It mentions either client authentication

---

From: Justin Richer <[email-masked]>
Date: Sun, 19 Jul 2015 21:14:05 +0200

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 uses to call several endpoints at the AS, including the introspection endpoint. In UMA, this PAT is given to the resource server through a normal OAuth transaction with an end user who facilitates the RS->AS introduction.

And I think this is all actually a moot point because clients shouldn’t be doing the introspection in the first place — the whole spec is there to support resource servers introspecting at the auth server. So you probably don’t have “public client resource servers” out there. We simply re-used OAuth’s existing client authentication mechanism, that doesn’t make them clients. This decision is based on development and deployment experience (as in, several people independently built it exactly this way). Do you have a use case where you’ve got a protected resource that can’t hold credentials (either a client secret or a public/private keypair) to authenticate with, and can’t be introduced using OAuth to the AS as in UMA?

To your other point: An attacker has less of a chance of getting information about a token by fishing at a protected resource with tokens, since they’re not being returned information about the token other than the fact that the token worked. (Or at least it seemed to work because a result came back — you could easily give a suspected attacker valid-looking-but-fake data as one mitigation mechanism.) The introspection response can give you information about where else the token could be used, potentially. Additionally, the RS really ought to be preventing data-fishing attacks like this just for its own sake anyway. There are lots of techniques for doing this, but they tend to be specific to the kind of API that’s being served.

Requiring the resource server to authenticate with the authorization server also allows you to do a few other useful things. Our implementation, for example, limits the token information that is returned to a particular AS. This allows us to have tokens that can be used in multiple RS’s without those RS’s ever even knowing the token is powerful enough to be used elsewhere. It prevents information about the authorization from leaking to parties who have no business knowing.

Hope this helps clarify it,
 — Justin

> On Jul 19, 2015, at 7:59 PM, Aaron Parecki <[email-masked]> wrote:
> 
> 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 fish against the resource server. In fact, if the resource server queries the introspection endpoint to check if tokens are valid, then that effectively gives an attacker a way to fish for tokens using the resource server's credentials. 
> 
> ---
> Aaron Parecki
> http://aaronparecki.com <http://aaronparecki.com/>
> 
> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: William Denniss <[email-masked]>
Date: Mon, 20 Jul 2015 00:03:44 +0200

I see in earlier drafts that client authentication MUST was a SHOULD.

Why not put it back to a SHOULD, and make these arguments in the Security
Considerations?  By the sound of it in some implementations there are good
reasons for doing client authentication, but they may not apply to
everyone, so do we need to be so prescriptive?  An error response can be
added for requests the server deems require client authentication.

It wouldn't have to be an all-or-nothing policy choice either, a server
could chose to reject requests from confidential clients where client
authentication is not provided, but accept requests without client
authentication from non-confidential clients.  A server that has
sufficiently high entropy in the tokens, abuse protection on the endpoint,
and is not concerned about an unrelated party (that happens to have a token
intended for a different party) learning the token metadata, could simply
not require any client authentication at all.

Apart from anything, it is really trivial to support non-confidential
client usage, so why not?  Perhaps there are some use-cases that will turn
up in the future (especially since as defined the introspection response is
extensible). One I can think of now is debugging: it's useful during
development to be able to inspect the tokens you get back from the AS.

Best,
William

On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <[email-masked]> wrote:

> 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
> uses to call several endpoints at the AS, including the introspection
> endpoint. In UMA, this PAT is given to the resource server through a normal
> OAuth transaction with an end user who facilitates the RS->AS introduction.
>
> And I think this is all actually a moot point because *clients* shouldn’t
> be doing the introspection in the first place — the whole spec is there to
> support *resource servers* introspecting at the auth server. So you
> probably don’t have “public client resource servers” out there. We simply
> re-used OAuth’s existing client authentication mechanism, that doesn’t make
> them clients. This decision is based on development and deployment
> experience (as in, several people independently built it exactly this way).
> Do you have a use case where you’ve got a protected resource that can’t
> hold credentials (either a client secret or a public/private keypair) to
> authenticate with, and can’t be introduced using OAuth to the AS as in UMA?
>
> To your other point: An attacker has less of a chance of getting
> information about a token by fishing at a protected resource with tokens,
> since they’re not being returned information about the token other than the
> fact that the token worked. (Or at least it seemed to work because a result
> came back — you could easily give a suspected attacker
> valid-looking-but-fake data as one mitigation mechanism.) The introspection
> response can give you information about where else the token could be used,
> potentially. Additionally, the RS really ought to be preventing
> data-fishing attacks like this just for its own sake anyway. There are lots
> of techniques for doing this, but they tend to be specific to the kind of
> API that’s being served.
>
> Requiring the resource server to authenticate with the authorization
> server also allows you to do a few other useful things. Our implementation,
> for example, limits the token information that is returned to a particular
> AS. This allows us to have tokens that can be used in multiple RS’s without
> those RS’s ever even knowing the token is powerful enough to be used
> elsewhere. It prevents information about the authorization from leaking to
> parties who have no business knowing.
>
>> How are public clients expected to use the token introspection endpoint?
>> I didn't see a note in the document about that at all.
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 Jul 2015 07:01:30 +0200

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 (which could also use RFC7591 to become non-public), but public resource servers don’t make nearly as much sense.

Additionally, the discussion for this was back in December during the WGLC, and the time for normative changes to this particular spec is largely over at this stage.

 — Justin

> On Jul 20, 2015, at 12:03 AM, William Denniss <[email-masked]> wrote:
> 
> Why not put it back to a SHOULD, and make these arguments in the Security Considerations?  By the sound of it in some implementations there are good reasons for doing client authentication, but they may not apply to everyone, so do we need to be so prescriptive?  An error response can be added for requests the server deems require client authentication.
> 
> It wouldn't have to be an all-or-nothing policy choice either, a server could chose to reject requests from confidential clients where client authentication is not provided, but accept requests without client authentication from non-confidential clients.  A server that has sufficiently high entropy in the tokens, abuse protection on the endpoint, and is not concerned about an unrelated party (that happens to have a token intended for a different party) learning the token metadata, could simply not require any client authentication at all.
> 
> Apart from anything, it is really trivial to support non-confidential client usage, so why not?  Perhaps there are some use-cases that will turn up in the future (especially since as defined the introspection response is extensible). One I can think of now is debugging: it's useful during development to be able to inspect the tokens you get back from the AS.
> 
> Best,
> William
> 
> 
> On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Jul 2015 07:04:13 +0200

Are you trying to use token introspection as evidence of authentication of the user?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Dominick Baier <[email-masked]>
Date: Mon, 20 Jul 2015 07:36:59 +0200

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 ([email-masked]) wrote:

 — Justin

Best,
William

---
Aaron Parecki
http://aaronparecki.com

 — Justin

----
Aaron Parecki
aaronparecki.com
@aaronpk

---

From: William Denniss <[email-masked]>
Date: Mon, 20 Jul 2015 09:34:35 +0200

Even if the primary target is the protected resource, is there a reason to
exclude use by clients?

The stated reason for this requirement in the spec is to prevent token
scanning, but there are other ways to prevent that.

On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer <[email-masked]> wrote:

> 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 (which
> could also use RFC7591 to become non-public), but public resource servers
> don’t make nearly as much sense.
>
> Additionally, the discussion for this was back in December during the
> WGLC, and the time for normative changes to this particular spec is largely
> over at this stage.
>
>  — Justin
>
>> And I think this is all actually a moot point because *clients*
>> shouldn’t be doing the introspection in the first place — the whole spec is
>> there to support *resource servers* introspecting at the auth server. So
>> you probably don’t have “public client resource servers” out there. We
>> simply re-used OAuth’s existing client authentication mechanism, that
>> doesn’t make them clients. This decision is based on development and
>> deployment experience (as in, several people independently built it exactly
>> this way). Do you have a use case where you’ve got a protected resource
>> that can’t hold credentials (either a client secret or a public/private
>> keypair) to authenticate with, and can’t be introduced using OAuth to the
>> AS as in UMA?
>>
>>> 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
>>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Jul 2015 09:38:26 +0200

Why does your client need/want to read the token?

Phil

@independentid
www.independentid.com
[email-masked]

> On Jul 20, 2015, at 9:34 AM, William Denniss <[email-masked]> wrote:
> 
> Even if the primary target is the protected resource, is there a reason to exclude use by clients?
> 
> The stated reason for this requirement in the spec is to prevent token scanning, but there are other ways to prevent that.
> 
> On Mon, Jul 20, 2015 at 7:01 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 20, 2015, at 12:03 AM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 Jul 2015 09:39:00 +0200

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 information, this should be specified as an extension to the token endpoint, in my opinion. Note that early drafts of this document targeted both clients and protected resources, but after discussion with both implementors and the working group, this was pulled back to just the resource server because that’s what people are doing with it. 

A single piece of software can be both an OAuth client and an OAuth protected resource, but those are two different roles in the system and shouldn’t be conflated.

 — Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 Jul 2015 09:39:29 +0200

Apologies, I did not mean read, but introspect the token.
Phil

@independentid
www.independentid.com
[email-masked]

> On Jul 20, 2015, at 9:38 AM, Phil Hunt <[email-masked]> wrote:
> 
> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
>> On Jul 20, 2015, at 9:34 AM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 20 Jul 2015 10:57:58 +0300

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 
introspect the endpoint would indeed conflate the roles, and overload 
the access token response protocol which provides all the info the 
actual client needs to know. The client only need to know the token info 
that lets it talk to the resource server, it does not need to introspect 
it like resource server does in order to make an authorization decision.

+1 to what Justin says...

Cheers, Sergey
On 20/07/15 10:39, Justin Richer wrote:
> 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 information, this should be specified as an extension to the token
> endpoint, in my opinion. Note that early drafts of this document
> targeted both clients and protected resources, but after discussion with
> both implementors and the working group, this was pulled back to just
> the resource server because that’s what people are doing with it.
>
> A single piece of software can be both an OAuth client and an OAuth
> protected resource, but those are two different roles in the system and
> shouldn’t be conflated.
>
>   — Justin
>
>>     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 (which could also use
>>     RFC7591 to become non-public), but public resource servers don’t
>>     make nearly as much sense.
>>
>>     Additionally, the discussion for this was back in December during
>>     the WGLC, and the time for normative changes to this particular
>>     spec is largely over at this stage.
>>
>>      — Justin
>>
>>>     On Jul 20, 2015, at 12:03 AM, William Denniss
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Why not put it back to a SHOULD, and make these arguments in the
>>>     Security Considerations?  By the sound of it in some
>>>     implementations there are good reasons for doing client
>>>     authentication, but they may not apply to everyone, so do we need
>>>     to be so prescriptive?  An error response can be added for
>>>     requests the server deems require client authentication.
>>>
>>>     It wouldn't have to be an all-or-nothing policy choice either, a
>>>     server could chose to reject requests from confidential clients
>>>     where client authentication is not provided, but accept requests
>>>     without client authentication from non-confidential clients.  A
>>>     server that has sufficiently high entropy in the tokens, abuse
>>>     protection on the endpoint, and is not concerned about an
>>>     unrelated party (that happens to have a token intended for a
>>>     different party) learning the token metadata, could simply not
>>>     require any client authentication at all.
>>>
>>>     Apart from anything, it is really trivial to support
>>>     non-confidential client usage, so why not?  Perhaps there are
>>>     some use-cases that will turn up in the future (especially since
>>>     as defined the introspection response is extensible). One I can
>>>     think of now is debugging: it's useful during development to be
>>>     able to inspect the tokens you get back from the AS.
>>>
>>>     Best,
>>>     William
>>>
>>>
>>>         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 uses
>>>         to call several endpoints at the AS, including the
>>>         introspection endpoint. In UMA, this PAT is given to the
>>>         resource server through a normal OAuth transaction with an
>>>         end user who facilitates the RS->AS introduction.
>>>
>>>         And I think this is all actually a moot point because
>>>         *clients* shouldn’t be doing the introspection in the first
>>>         place — the whole spec is there to support *resource servers*
>>>         introspecting at the auth server. So you probably don’t have
>>>         “public client resource servers” out there. We simply re-used
>>>         OAuth’s existing client authentication mechanism, that
>>>         doesn’t make them clients. This decision is based on
>>>         development and deployment experience (as in, several people
>>>         independently built it exactly this way). Do you have a use
>>>         case where you’ve got a protected resource that can’t hold
>>>         credentials (either a client secret or a public/private
>>>         keypair) to authenticate with, and can’t be introduced using
>>>         OAuth to the AS as in UMA?
>>>
>>>         To your other point: An attacker has less of a chance of
>>>         getting information about a token by fishing at a protected
>>>         resource with tokens, since they’re not being returned
>>>         information about the token other than the fact that the
>>>         token worked. (Or at least it seemed to work because a result
>>>         valid-looking-but-fake data as one mitigation mechanism.) The
>>>         introspection response can give you information about where
>>>         else the token could be used, potentially. Additionally, the
>>>         RS really ought to be preventing data-fishing attacks like
>>>         this just for its own sake anyway. There are lots of
>>>         techniques for doing this, but they tend to be specific to
>>>         the kind of API that’s being served.
>>>
>>>         Requiring the resource server to authenticate with the
>>>         authorization server also allows you to do a few other useful
>>>         things. Our implementation, for example, limits the token
>>>         information that is returned to a particular AS. This allows
>>>         us to have tokens that can be used in multiple RS’s without
>>>         those RS’s ever even knowing the token is powerful enough to
>>>         be used elsewhere. It prevents information about the
>>>         authorization from leaking to parties who have no business
>>>         knowing.
>>>
>>>>         On Jul 19, 2015, at 7:59 PM, Aaron Parecki
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         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 fish against the resource server. In fact, if the
>>>>         resource server queries the introspection endpoint to check
>>>>         if tokens are valid, then that effectively gives an attacker
>>>>         a way to fish for tokens using the resource server's
>>>>         credentials.
>>>>
>>>>         ---
>>>>         Aaron Parecki
>>>>         On Sat, Jul 18, 2015 at 10:04 PM Justin Richer
>>>>         <[email-masked] <mailto:[email-masked]>> 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 Parecki
>>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>             The introspection draft states that the introspection
>>>>>             endpoint MUST require authentication of clients. It
>>>>>             mentions either client authentication (id+secret) or a
>>>>>             separate bearer token.
>>>>>
>>>>>             How are public clients expected to use the token
>>>>>             introspection endpoint? I didn't see a note in the
>>>>>             document about that at all.
>>>>>
>>>>>             ----
>>>>>             Aaron Parecki

---

From: William Denniss <[email-masked]>
Date: Mon, 20 Jul 2015 11:29:10 +0200

Currently we recommend clients validate the audience of access tokens they
receive over the implicit flow to protect against a confused deputy attack.
This recommendation is documented here:
https://developers.google.com/identity/protocols/OAuth2UserAgent#validatetoken.
John
talks about this attack on his blog:
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
and
it's documented as a security concern in OAuth2
http://tools.ietf.org/html/rfc6749#section-10.16

We have a non-standard "tokeninfo" endpoint for this validation (which
doesn't require client authentication, but there are abuse protections in
place). This spec is actually very close to our endpoint (we even moved
towards JWT parameter names in the latest version [v3]).

We're not alone, WordPress have an introspection endpoint for OAuth2 tokens
that looks very similar to our own in terms of functionality and intent
https://developer.wordpress.com/docs/oauth2/#making-an-api-call  Facebook
also supports token introspection for clients
https://developers.facebook.com/docs/facebook-login/access-tokens#debug

Even though this use-case is quite different, the endpoint is nearly
identical in functionality. Is "designed for resource servers" a strong
enough reason to exclude other use?

As far as I can tell, the only thing preventing reuse of the spec for this
purpose is that MUST.

On Mon, Jul 20, 2015 at 9:39 AM, Phil Hunt <[email-masked]> wrote:

>>> there to support *resource servers* introspecting at the auth server.
>>> So you probably don’t have “public client resource servers” out there. We
>>> 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 fish against the resource server. In fact, if the resource
>>> server queries the introspection endpoint to check if tokens are valid,
>>> then that effectively gives an attacker a way to fish for tokens using the
>>> resource server's credentials.
>>>
>>> ---
>>> Aaron Parecki
>>> http://aaronparecki.com
>>>
>>>> How are public clients expected to use the token introspection
>>>> endpoint? I didn't see a note in the document about that at all.
>>>>
>>>> ----
>>>> Aaron Parecki
>>>> aaronparecki.com

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Jul 2015 14:57:56 +0200

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 and preventing certain types of information
disclosure (maybe a client seeing info in an encrypted token or opaque
reference token).

We implemented introspection type functionality in our initial OAuth
product support well before the WG introspection document existed. It's got
basically similar concepts but just with a different syntax and endpoint.
The original release of it required authentication but we later relaxed
that requirement based on deployment feedback. So that's a data-point based
on experience that's maybe worth considering. Though I realize the document
is probably too far along in the process for changes at this point.

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 20 Jul 2015 10:49:14 -0700

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
is valid and find out the user ID associated with it?

----
Aaron Parecki
aaronparecki.com

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Jul 2015 21:11:11 +0200

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 <[email-masked]> wrote:
> 
> 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 is valid and find out the user ID associated with it?
> 
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 20 Jul 2015 19:34:22 +0000

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
sign in again if not.

Aaron

On Mon, Jul 20, 2015 at 12:11 PM John Bradley <[email-masked]> wrote:

> 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
>
> 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 is valid and find out the user ID associated with it?
>
> ----
> Aaron Parecki
> aaronparecki.com

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Jul 2015 23:18:19 +0200

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 endpoint.   If it is a sticky grant you could use prompt=none in a iframe to see if the user is logged in.

I don’t see a introspection endpoint for the client adding anything in reality.

It may cause problems if clients start sniffing the content of AT and information is leaked or people start making decisions based on a token that is supposed to be opaque.

John B.

> On Jul 20, 2015, at 9:34 PM, Aaron Parecki <[email-masked]> wrote:
> 
> 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 sign in again if not. 
> 
> Aaron
> 
> On Mon, Jul 20, 2015 at 12:11 PM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> On Jul 20, 2015, at 7:49 PM, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Jul 2015 10:03:51 +0200

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

---

From: William Denniss <[email-masked]>
Date: Wed, 22 Jul 2015 01:05:47 +0200

We had a good sync on this topic offline on Monday, and it seemed the
consensus was that if clients need to introspect access tokens they are
doing something wrong.

That said, looking only at the resource server use-case, I still think the
MUST is problematic.

The out of band authentication requirement when accompanied with the MUST
makes the spec less useful.  i.e. "the endpoint MUST also require some form
of authorization to access this endpoint", but "The specifics of this
authentication credentials are out of scope of this specification".  This
makes dynamic discovery which was mentioned as potentially applying to this
spec virtually useless (you discovered the introspection endpoint, but how
do you discover how to authenticate?). It also adds to general
implementation complexity.

Brian mentioned that in their implementation, they decided not to force
authentication for introspection by resource servers as they were
protecting the endpoint through other means, and wanted to reduce
complexity for developers. The MUST here constrains that decision, one
which I think should be left up to the provider.

Lastly, the MUST is presented in the spec as being required to prevent
token scanning, and yet there are other ways to mitigate that attack. If
there are better reasons than token scanning for this remaining a MUST,
then I think the spec should document them.

Side note: If you prevent token scanning through other means, the main
benefit of still requiring authentication seems to be preventing
information leaking out to a client who is in possession of the access
token but isn't the intended audience. This may or may not be an issue
depending on the contents of the introspection response. Perhaps it would
be good to mention this in the security considerations, as it's something
that should be considered by implementors.  Given the sensitivity of
information revealed by the introspection endpoint varies, I don't think
that this alone would mandate the MUST.

On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer <[email-masked]> wrote:

> 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
>
> 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 sign in again if not.
>
> Aaron
>
>>> Security Considerations?  By the sound of it in some implementations there
>>> are good reasons for doing client authentication, but they may not apply to
>>>> 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,

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 22 Jul 2015 11:42:44 +0300

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 follow-up validation of the token properties for 
public clients given that the access token endpoint can support public 
clients and is dedicated to working with the clients.

Purely from a technical point of view it seems not a big deal to relax 
it back to SHOULD, but I wonder if having the introspection endpoint 
supporting different roles (public clients, resource servers, with some 
requiring the auth and some not) would make it more difficult to do the 
extra work for getting PoP token introspection supported, etc...

My 2c, thanks, Sergey
On 22/07/15 02:05, William Denniss wrote:
> That said, looking only at the resource server use-case, I still think
> the MUST is problematic.
>
> The out of band authentication requirement when accompanied with the
> MUST makes the spec less useful.  i.e. "the endpoint MUST also require
> some form of authorization to access this endpoint", but "The specifics
> of this authentication credentials are out of scope of this
> specification".  This makes dynamic discovery which was mentioned as
> potentially applying to this spec virtually useless (you discovered the
> introspection endpoint, but how do you discover how to authenticate?).
> It also adds to general implementation complexity.
>
> depending on the contents of the introspection response. Perhaps it
> would be good to mention this in the security considerations, as it's
> something that should be considered by implementors.  Given the
> sensitivity of information revealed by the introspection endpoint
> varies, I don't think that this alone would mandate the MUST.
>
>
>
> On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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 <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     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 sign in again if not.
>>
>>     Aaron
>>
>>         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
>>
>>>         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
>>>         On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer
>>>             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 (which could also use RFC7591 to become
>>>             non-public), but public resource servers don’t make
>>>             nearly as much sense.
>>>
>>>             Additionally, the discussion for this was back in
>>>             December during the WGLC, and the time for normative
>>>             changes to this particular spec is largely over at this
>>>             stage.
>>>
>>>              — Justin
>>>
>>>>             Why not put it back to a SHOULD, and make these
>>>>             arguments in the Security Considerations?  By the sound
>>>>             of it in some implementations there are good reasons for
>>>>             doing client authentication, but they may not apply to
>>>>             everyone, so do we need to be so prescriptive?  An error
>>>>             response can be added for requests the server deems
>>>>             require client authentication.
>>>>
>>>>             It wouldn't have to be an all-or-nothing policy choice
>>>>             either, a server could chose to reject requests from
>>>>             confidential clients where client authentication is not
>>>>             provided, but accept requests without client
>>>>             authentication from non-confidential clients.  A server
>>>>             that has sufficiently high entropy in the tokens, abuse
>>>>             protection on the endpoint, and is not concerned about
>>>>             an unrelated party (that happens to have a token
>>>>             intended for a different party) learning the token
>>>>             metadata, could simply not require any client
>>>>             authentication at all.
>>>>
>>>>             non-confidential client usage, so why not?  Perhaps
>>>>             there are some use-cases that will turn up in the future
>>>>             (especially since as defined the introspection response
>>>>             is extensible). One I can think of now is debugging:
>>>>             it's useful during development to be able to inspect the
>>>>             tokens you get back from the AS.
>>>>
>>>>             Best,
>>>>             William
>>>>
>>>>
>>>>             On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer
>>>>                 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 uses to call
>>>>                 several endpoints at the AS, including the
>>>>                 introspection endpoint. In UMA, this PAT is given to
>>>>                 the resource server through a normal OAuth
>>>>                 transaction with an end user who facilitates the
>>>>                 RS->AS introduction.
>>>>
>>>>                 And I think this is all actually a moot point
>>>>                 because *clients* shouldn’t be doing the
>>>>                 introspection in the first place — the whole spec is
>>>>                 there to support *resource servers* introspecting at
>>>>                 the auth server. So you probably don’t have “public
>>>>                 client resource servers” out there. We simply
>>>>                 re-used OAuth’s existing client authentication
>>>>                 mechanism, that doesn’t make them clients. This
>>>>                 decision is based on development and deployment
>>>>                 experience (as in, several people independently
>>>>                 built it exactly this way). Do you have a use case
>>>>                 where you’ve got a protected resource that can’t
>>>>                 hold credentials (either a client secret or a
>>>>                 public/private keypair) to authenticate with, and
>>>>                 can’t be introduced using OAuth to the AS as in UMA?
>>>>
>>>>                 To your other point: An attacker has less of a
>>>>                 chance of getting information about a token by
>>>>                 fishing at a protected resource with tokens, since
>>>>                 they’re not being returned information about the
>>>>                 token other than the fact that the token worked. (Or
>>>>                 at least it seemed to work because a result came
>>>>                 back — you could easily give a suspected attacker
>>>>                 valid-looking-but-fake data as one mitigation
>>>>                 mechanism.) The introspection response can give you
>>>>                 information about where else the token could be
>>>>                 used, potentially. Additionally, the RS really ought
>>>>                 to be preventing data-fishing attacks like this just
>>>>                 for its own sake anyway. There are lots of
>>>>                 techniques for doing this, but they tend to be
>>>>                 specific to the kind of API that’s being served.
>>>>
>>>>                 Requiring the resource server to authenticate with
>>>>                 the authorization server also allows you to do a few
>>>>                 other useful things. Our implementation, for
>>>>                 example, limits the token information that is
>>>>                 returned to a particular AS. This allows us to have
>>>>                 tokens that can be used in multiple RS’s without
>>>>                 those RS’s ever even knowing the token is powerful
>>>>                 enough to be used elsewhere. It prevents information
>>>>                 about the authorization from leaking to parties who
>>>>                 have no business knowing.
>>>>
>>>>>                 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 fish against the
>>>>>                 resource server. In fact, if the resource server
>>>>>                 queries the introspection endpoint to check if
>>>>>                 tokens are valid, then that effectively gives an
>>>>>                 attacker a way to fish for tokens using the
>>>>>                     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
>>>>>
>>>>>>                     authentication of clients. It mentions either
>>>>>>                     client authentication (id+secret) or a
>>>>>>                     separate bearer token.
>>>>>>
>>>>>>                     How are public clients expected to use the
>>>>>>                     token introspection endpoint? I didn't see a
>>>>>>                     note in the document about that at all.
>>>>>>
>>>>>>                     ----
>>>>>>                     Aaron Parecki

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 26 Jul 2015 11:48:13 -0700

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
verifying an access token. I think the part that threw me off was that
OAuth 2.0 client authentication was mentioned as one of the mechanisms of
providing authorization to use the introspection endpoint:
https://tools.ietf.org/html/draft-ietf-oauth-introspection-11#section-2.1
Hopefully that feedback is helpful.

That said, I also agree with William's assessment.

----
Aaron Parecki
aaronparecki.com