On Jul 20, 2015, at 12:03 AM, William Denniss
<wdenn...@google.com <mailto: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
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
