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 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 > > >> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer <jric...@mit.edu> 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 <wdenn...@google.com> 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 <jric...@mit.edu> 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 <aa...@parecki.com> 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 <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 Parecki <aa...@parecki.com> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
