Hi
Would there be any sense at all to have a new endpoint dedicated to
supporting public clients only for these clients be able to do the extra
validation which only public clients may need, etc, etc.
Or perhaps let the access token endpoint not only exchange grants but
also do some optional follow-up validation of the token properties for
public clients given that the access token endpoint can support public
clients and is dedicated to working with the clients.
Purely from a technical point of view it seems not a big deal to relax
it back to SHOULD, but I wonder if having the introspection endpoint
supporting different roles (public clients, resource servers, with some
requiring the auth and some not) would make it more difficult to do the
extra work for getting PoP token introspection supported, etc...
My 2c, thanks, Sergey
On 22/07/15 02:05, William Denniss wrote:
We had a good sync on this topic offline on Monday, and it seemed the
consensus was that if clients need to introspect access tokens they are
doing something wrong.
That said, looking only at the resource server use-case, I still think
the MUST is problematic.
The out of band authentication requirement when accompanied with the
MUST makes the spec less useful. i.e. "the endpoint MUST also require
some form of authorization to access this endpoint", but "The specifics
of this authentication credentials are out of scope of this
specification". This makes dynamic discovery which was mentioned as
potentially applying to this spec virtually useless (you discovered the
introspection endpoint, but how do you discover how to authenticate?).
It also adds to general implementation complexity.
Brian mentioned that in their implementation, they decided not to force
authentication for introspection by resource servers as they were
protecting the endpoint through other means, and wanted to reduce
complexity for developers. The MUST here constrains that decision, one
which I think should be left up to the provider.
Lastly, the MUST is presented in the spec as being required to prevent
token scanning, and yet there are other ways to mitigate that attack. If
there are better reasons than token scanning for this remaining a MUST,
then I think the spec should document them.
Side note: If you prevent token scanning through other means, the main
benefit of still requiring authentication seems to be preventing
information leaking out to a client who is in possession of the access
token but isn't the intended audience. This may or may not be an issue
depending on the contents of the introspection response. Perhaps it
would be good to mention this in the security considerations, as it's
something that should be considered by implementors. Given the
sensitivity of information revealed by the introspection endpoint
varies, I don't think that this alone would mandate the MUST.
On Tue, Jul 21, 2015 at 10:03 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@mit.edu>> wrote:
Just use the token at your target API and see if it works. Your
client’s going to need to be able to get a new token if this one
expires mid-session anyway, so you’re not saving anything by doing
an introspection request.
— Justin
On Jul 20, 2015, at 9:34 PM, Aaron Parecki <aa...@parecki.com
<mailto:aa...@parecki.com>> wrote:
I'm looking for a way to check if an existing token is still
valid. Imagine a client is holding on to a token between user
sessions, for example if it's making API requests for the user on
a cron job. When the user returns to the site, I want to check if
the token is still valid, and make them sign in again if not.
Aaron
On Mon, Jul 20, 2015 at 12:11 PM John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
If you want the resource owner/user then get a id_token from
the token endpoint. That saves another call to a
introspection endpoint.
Sent from my iPhone
On Jul 20, 2015, at 7:49 PM, Aaron Parecki <aa...@parecki.com
<mailto:aa...@parecki.com>> wrote:
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 <http://aaronparecki.com/>
@aaronpk <http://twitter.com/aaronpk>
On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer
<jric...@mit.edu <mailto: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 <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
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
