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

[Aaron Parecki <[e-mail]>]

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
@aaronpk <http://twitter.com/aaronpk>


On Tue, Jul 21, 2015 at 4:05 PM, William Denniss <[e-mail]>
wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>
>>> On Jul 20, 2015, at 7:49 PM, Aaron Parecki <[e-mail]> 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 <http://twitter.com/aaronpk>
>>>
>>>
>>> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer <[e-mail]> 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
>>>>
>>>> On Jul 20, 2015, at 12:03 AM, William Denniss <[e-mail]>
>>>> wrote:
>>>>
>>>> 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 <[e-mail]> 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.
>>>>>
>>>>> Hope this helps clarify it,
>>>>>  — Justin
>>>>>
>>>>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki <[e-mail]> wrote:
>>>>>
>>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]> 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
>>>>>> aaronparecki.com
>>>>>> @aaronpk <http://twitter.com/aaronpk>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>