Are you trying to use token introspection as evidence of authentication of the user?
Phil @independentid www.independentid.com phil.h...@oracle.com > 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 > <mailto: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 >> <mailto: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 <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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
