So what?
The request is OK (no missing parameter, etc.) so a 400 is not appropriate
(it could still be used, but you couldn't tell what went wrong without
*also* having some well-defined error response document format; and an
"invalid_token" error code wouldn't work if you're also using token
authentication passed in the form-encoded body ⇒ too much confusion, not
worth it).
401 or 403 are obviously not appropriate either.
I'm +1000 on keeping the 200 OK response with {"active":false} JSON
response.
On Tue Dec 02 2014 at 18:27:03 Donald Coffin <donald.cof...@reminetworks.com>
wrote:
> Hi Justin,
>
>
>
> I believe you will find the answer to which HTTP Status code the AS should
> return if the token is INACTIVE in Section 3.1 Error Codes of “The OAuth
> 2.0 Framework: Bearer Token Usage” [RFC6750] which states:
>
>
>
> 3.1. Error Codes
>
> When a request fails, the resource server responds using the appropriate
> HTTP status code (typically, 400, 401, 403, or 405) and includes one of the
> following error codes in the response:
>
>
>
> *invalid_request*
>
> The request is missing a required parameter, includes an unsupported
> parameter or parameter value, repeats the same parameter, uses more than
> one method for including an access token, or is otherwise malformed. The
> resource server SHOULD respond with the HTTP 400 (Bad Request) status code.
>
>
>
> *invalid_token*
>
> The access token provided is expired, revoked, malformed, or invalid for
> other reasons. The resource SHOULD respond with the HTTP 401 (Unauthorized)
> status code. The client MAY request a new access token and retry the
> protected resource request.
>
>
>
> *insufficient_scope*
>
> The request requires higher privileges than provided by the access token.
> The resource server SHOULD respond with the HTTP 403 (Forbidden) status
> code and MAY include the scope attribute with the scope necessary to access
> the protected resource.
>
>
>
> If the request lacks any authentication information (e.g., the client was
> unaware that authentication is necessary or attempted using an unsupported
> authentication method), the resource server SHOULD NOT include an error
> code or other error information.
>
>
>
> For example:
>
> HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example"
>
>
>
>
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
>
>
> REMI Networks
>
> 22751 El Prado Suite 6216
>
> Rancho Santa Margarita, CA 92688-3836
>
>
>
> Phone: (949) 636-8571
>
> Email: donald.cof...@reminetworks.com
>
>
>
> *From:* Justin Richer [mailto:jric...@mit.edu]
> *Sent:* Tuesday, December 2, 2014 6:06 AM
> *To:* Hannes Tschofenig; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01
>
>
>
> Hannes, thanks for the review. Comments inline.
>
> On 12/2/2014 6:23 AM, Hannes Tschofenig wrote:
>
> Hi Justin,
>
>
>
> I have a few remarks regarding version -01 of the token introspection
>
> document.
>
>
>
> * Terminology
>
>
>
> The token introspection protocol is a client-server protocol but the
>
> term "client" already has a meaning in OAuth. Here the client of the
>
> token introspection protocol is actually the resource server. I believe
>
> it would make sense to clarify this issue in the terminology section or
>
> in the introduction. Maybe add a figure (which you could copy from
>
> Figure 4 of
>
> http://www.ietf.org/id/draft-ietf-oauth-pop-architecture-00.txt.
>
>
>
> Maybe you want to call these two parties, the introspection client and
>
> the introspection server.
>
>
> I tried to avoid the word "client" for this very reason. The draft used to
> say "client or protected resource" throughout, but in a few years of
> deployment experience it's become clear that it's pretty much just
> protected resources that need to do introspection so I changed that text
> throughout. I don't think that "introspection client" will help here
> because the party already has a name from OAuth and we should inherit it.
>
>
> * Scope
>
>
>
> I think the document needs to be very clear that is only applicable to
>
> bearer tokens (and not to PoP tokens). This issue was raised at the last
>
> IETF meeting as well.
>
>
> I think the document should be clear that it *specifies* the mechanism for
> bearer tokens, since that's the only OAuth token type that's defined
> publicly right now, and that the details for PoP will have to be specified
> in another spec -- that's exactly what Appendix C is there for, and if that
> can be clearer, please suggest better text.
>
> However, I think it's very clear how PoP tokens would work. You send the
> value returned as the "access_token" in the token endpoint response, which
> is effectively the public portion of the PoP token. Just like a bearer
> token, this value is passed as-is from the client to the RS and would be
> passed as-is from the RS to the AS during introspection. The AS can then
> use that to look up the key and return it in an as-yet-unspecified field so
> that the RS can validate the request. The RS wouldn't send the signature or
> signed portion of the request for the AS to validate -- that's a bad idea.
> But these are all details that we can work out in the PoP-flavored
> extension. As I noted in the other thread, we'll have to make a similar
> extension for Revocation, so I still don't think it makes sense to hold up
> this work and wait for PoP to be finished because it's useful now, as-is.
>
>
>
>
>
>
> * Meta-Information
>
>
>
> You have replicated a lot of the claims defined in
>
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-31
>
> and I am wondering why you have decided to not just re-use the entire
>
> registry from JWT?
>
>
>
> If you want to create a separate registry (which I wouldn't recommend)
>
> then you have to put text into the IANA consideration section.
>
>
> The idea was to inherit JWT's syntax and semantics, at least on the wire,
> and add additional fields. It probably makes sense to just inherit the JWT
> registry, so we can do that.
>
>
> When you write:
>
>
>
> "
>
> The endpoint MAY allow other parameters to provide further context to
>
> the query.
>
> "
>
>
>
> You could instead write that the token introspection MUST ignore any
>
> parameters from the request message it does not understand.
>
>
> Noted, will add.
>
>
> Of course, there is the question whether any of those would be security
>
> critical and hence ignoring them would cause problems?!
>
>
> Anything security critical would be provider-specific, in which case it
> wouldn't ignore them.
>
>
> * Security
>
>
>
> The requirement for authenticating the party issuing the introspection
>
> request to the token introspection endpoint is justified in the security
>
> and the privacy consideration section. The security threat is that an
>
> attacker could use the endpoint to testing for tokens. The privacy
>
> threat is that a resource server learns about the content of the token,
>
> which may contain personal data. I see the former as more dangerous than
>
> the latter since a legitimate resource server is supposed to learn about
>
> the authorization information in the token. An attacker who had gotten
>
> hold of tokens will not only learn about the content of the token but he
>
> will also be able to use it to get access to the protected resource itself.
>
>
>
> In any case, to me this sounds like mutual authentication should be
>
> mandatory to implement. This is currently not the case. On top of that
>
> there is single technique mandatory-to-implement outlined either (in
>
> case someone wants to use it). That's in general not very helpful from
>
> an interoperability point of view. Yet another thing to agree on between
>
> the AS and the RS.
>
>
> I had similar thoughts when putting draft -01 together but didn't want to
> make a normative change like that without the WG input. I'm fine with
> strengthening this to a MUST, since as far as I'm aware that's how it works
> in all existing implementations (can anyone else comment on this?). I'm
> less comfortable with making one particular mechanism MTI, since I know of
> implementations that use either a special set of credentials passed just
> like client credentials to the token endpoint, or an OAuth token
> specifically for the introspection endpoint. If we do standardize on one
> MTI form, I'd suggest that we make it the OAuth bearer token.
>
>
> * SHOULDs
>
>
>
> This is my usual comment that any SHOULD statement should give the
>
> reader enough information about the trade-off decision he has to make.
>
> When should he implement something and when should he skip it?
>
>
> Noted, thanks.
>
>
> * Minor items
>
>
>
> You write:
>
>
>
> "
>
> These include using
>
> structured token formats such as JWT [JWT] or SAML [[ Editor's Note:
>
> Which SAML document should we reference here? ]] and proprietary
>
> inter-service communication mechanisms (such as shared databases and
>
> protected enterprise service buses) that convey token information.
>
> "
>
>
>
> Just reference the JWT since that's what we standardize.
>
>
> I'm fine with that, didn't want to offend the SAML cabal but we can cut it.
>
>
> * 'Active' claim
>
>
>
> you write:
>
> "
>
> active REQUIRED. Boolean indicator of whether or not the presented
>
> token is currently active. The authorization server determines
>
> whether and when a given token is in an active state.
>
> "
>
>
>
> Wouldn't it make more sense to return an error rather than saying that
>
> this token is not active.
>
>
> It's not an error, really. It's a valid request and valid response saying
> that token isn't any good. It would be easy enough to change the returned
> error code on the {active:false} response, but to which code? The request
> isn't Forbidden, or Not Found (the token could have been found but it's
> been deactivated or just not available to the RS that's asking for it), or
> Unauthorized, or even a Bad Request. So my logic is that the response is
> "OK", but the content of the response tells you the metadata about the
> token, which is that it's not active.
>
>
> * Capitalization
>
>
>
> Reading through the text I see bearer token/Bearer Token, Client/client,
>
> etc. issue.
>
>
> Thanks, still breaking old Bad Habits of capitalizing Terms In The
> Document. Tried to clean it up, will do more.
>
>
> * AS <-> RS relationship
>
>
>
> You write:
>
> "
>
> Since
>
> OAuth 2.0 [RFC6749] defines no direct relationship between the
>
> authorization server and the protected resource, only that they must
>
> have an agreement on the tokens themselves, there have been many
>
> different approaches to bridging this gap.
>
> "
>
>
>
> I am not sure what you mean by "defines no relationship" between the AS
>
> and the RS. Of course, there is a relationship. The AS issues tokens for
>
> access for a specific RS. The RS needs to understand the tokens or if it
>
> does not understand them it needs to know which AS to interact with to
>
> learn about the content.
>
>
>
> In a nutshell, I am not sure what you want to say with this paragraph
>
> particularly since you state that they have to have an agreement about
>
> the tokens.
>
>
> What I was trying to point out is that it doesn't define the nature of the
> relationship between the two components. Specifically, it says:
>
> The methods used by the resource
>
> server to validate the access token (as well as any error responses)
>
> are beyond the scope of this specification but generally involve an
>
> interaction or coordination between the resource server and the
>
> authorization server.
>
> This spec provides one mechanism for this validation. So we could
> reference this directly if that's helpful.
>
> -- Justin
>
>
>
>
>
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
>
> _______________________________________________
>
> 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
