Thanks for the feedback.
I agree that the spec is not badly designed over all. I just think that the
MUST is a bit too restrictive, especially with how none of the OAuth grants
requires authentication to begin with except when a client is Confidential or
when using Client Credential flow (for obvious reasons).
I don't believe that simply using a token to determine its validity is a good
course of action. There may very well be unintended side-effects (like the
issuance of a new refresh/access token when using a refresh token at the Token
endpoint, or one-time use access tokens). One use case presented by Kévin
Chalet is when a client might need to determine and what users it has been
authorized access on behalf of and possibly remove those that are no longer
valid. Another might be something like determining if an initial one-time use
access token for registration requests is still active and available to use for
client registration.
Not having available resources or libraries to validate JWTs or other tokens on
the client was another use case mentioned in discussions we had. I'm glad
others have had similar discussions for this scenario.
That being said, the idea of using the token itself for authentication
intrigues me, though doesn't that inherently break the entire point of having
the authentication be a MUST in the spec to begin with? How might an
Authorization Server mitigate inherent security risks with this approach for
any type of tokens?
-----Original Message-----
From: "William Denniss" <wdenn...@google.com>
Sent: 11/2/2015 6:58 PM
To: "Justin Richer" <jric...@mit.edu>; "Michael Ciarlillo"
<michael.ciarli...@gmail.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues
We had a debate on that MUST at the last IETF, but the spec was too far along
to change. The workaround is to treat the token you are introspecting as the
authentication. With that workaround, the spec is quite usable for
non-confidential clients, even if resource servers were the primary target.
Google currently runs an introspection endpoint of sorts for clients, named
"tokeninfo", and the latest version (v3) is close to the spec (coincidence -
it's a good design pattern). Aimed mostly at debugging use-cases or if you
don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer <jric...@mit.edu> wrote:
Hi Michael,
Thanks for the comments. First off, the text of an RFC is fixed and cannot be
changed. The spec can only be altered with a new document that obsoletes
RFC7662, which would have to go through the working group process again from
the very beginning.
Authentication is required but we’re open to how it happens. The introspection
spec is targeted at resource servers, not clients, since a client can always
just *use* the token in order to see if it’s valid or not. Why bother with the
extra round trip to check if the token is good before trying it, since trying
it will also tell you if the token’s good? The recovery process for a failed
token is the same in either state. We initially had this written for either
clients or protected resources, but that’s not how people were using it and
restricting its focus helped clarify the spec immensely.
ID tokens are a slightly different case as they’re an assertion targeted at the
client itself, but in those cases an ID token is really meant to be
self-contained as a JWT, and generally has a short validity period. If you’re
looking to introspect an old ID token to check an OIDC session status, then you
might be better served implementing one of the OIDC session spec components for
that purpose.
Also, we didn’t mandate a specific authentication technology. Most people are
going to use either client authentication or a specific OAuth token designed
for this purpose. The latter of these is technically available for public
clients, but then you have the question of if you want to check the status of
*that* token too. Still, I think that for any clients (including public ones)
the right thing to do is just use the token and see if it works.
To the other comment, HTTP POST is the only defined verb and we’re silent on
the use of other verbs. That said, many HTTP implementation frameworks don’t
differentiate between verbs for requests and so a POST with body form
parameters and a GET with query parameters would come out the same. We don’t
outright prohibit this behavior, but it’s off-label and there are security
considerations for its use.
Hope this helps,
— Justin
On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo <michael.ciarli...@gmail.com>
wrote:
Hello all,
I have a couple of comments/issues with the RFC at
https://tools.ietf.org/html/rfc7662.
According to Section 2.1 (Introspection Request) says that "To prevent token
scanning attacks, the endpoint MUST also require some form of authorization to
access this endpoint..." This might make sense for token introspection requests
only coming from Resource Servers, but to many implementers it makes sense to
allow Clients access to the introspection endpoint since it would serve the
same purpose (token validity checking, particularly for refresh tokens, but
also for access tokens, or identity tokens in OpenID Connect, or possibly other
token types in UMA and other specs). Unfortunately, this means that public
clients should be accounted for in some way, as refresh tokens don't have an
explicit requirement in the OAuth 2.0 spec that they be issued only to
Confidential Clients. As such, many implementers don't feel like the
Introspection spec fits well for Client consumption because of the "MUST"
requirement on authentication, when public clients won't have a Client Secret
to authenticate with. Further, token scanning attacks would not be mitigated
for authenticated callers (be they Resource Servers or Clients).
An example of a real-world implementer discussion talking about this topic is
one I had with Kévin Chalet:
https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159
We are not the only ones who see this as a problem with the spec, and there do
not seem to be many concrete reasons for this endpoint ONLY being for Resource
Servers themselves. Can some insight into why this is the case? Can the MUST be
changed to a SHOULD with the Security Considerations section expanded to talk
about the issue? If not, is there another spec or draft out there somewhere for
OAuth token validity for which the intent is explicitly client consumption? Any
and all feedback on this would be greatly appreciated as we develop the ASOS
middleware project.
Another (small) comment on the spec: Section 2.1 (Introspection Request)
currently says that requests be HTTP POST method requests, however Section 4
(Security Considerations) mentions Authorization Servers explicitly disallowing
the GET method due to server logs. What is the requirement here? POST with
optional GET or explicitly only allowing POST requests?
Sincerely,
Michael Ciarlillo
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
