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