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 <http://aaronparecki.com/> > > On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <jric...@mit.edu > <mailto: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 >> <mailto: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 <http://aaronparecki.com/> >> @aaronpk <http://twitter.com/aaronpk> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
