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
