I'm not understanding how these different cases matter to the client? I
doubt that the running code will be able to dynamically handle the
error. So it seems this information is only relevant to the developers
and not relevant from an end user and the client perspective.
Also, for the 5 states you define, the effect of calling revocation is
still that the token is "revoked" because the token is already not valid.
So from an implementation perspective, where is the concern that
developer will do the "wrong thing" without these more detailed error
responses?
Thanks,
George
On 5/19/18 5:41 PM, Sergey Ponomarev wrote:
Hi,
I developing an implementation of back channel token revocation
endpoint. And I think we should reconsider and probably change the
specification to improve error handling.
Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JWT or JWT with invalid signature
3. token is expired or token is evenunknown
4. token was already revoked
5. token type is unsupported
According to RFC7009 OAuth 2.0 Token Revocation
<https://tools.ietf.org/html/rfc7009> section 2.2 Revocation Response:
The authorization server responds with HTTP status code 200 if the
token has been revoked successfully or if the client submitted an
invalid token.
Note: invalid tokens do not cause an error response since the
client cannot handle such an error in a reasonable way. Moreover,
the purpose of the revocation request, invalidating the particular
token, is already achieved..
As you may see this section covers only case 3 and case 4 but it's
very unclear: calling token as "invalid" is very broad definition.
I think we should take a look on each case separately:
1. token wasn't sent in request.
Most implementations returns 400 status code,error:
"invalid_request", error_description": "Missing required parameter:
token".
Note that returned error is not "invalid_token" but "invalid_request"
and I think this should be correct behavior and should be clearly
specified.
2. token is invalid by format i.e. not JWT or JWT with invalid signature
This error is mostly related to JWT but for reference (opaque) tokens
can be also applied (e.g. token is too long).
Goolge OAuth returns 400 code with "error": "invalid_token" and I
think this is correct behavior.
The client can have a bug and sends invalid tokens so we should return
an error response instead of 200 status.
3. token is expired or even unknown
Spec says that IdP should return 200 in this case but in case of
unknown token this may be a symptom of a bug on client side. Even if
IdP can clearly determine that token is expired (in case of JWT) this
is hard to determine in case of reference token that was removed from DB.
So personally I think that from security perspective it's better to
response with 400 status because client can have a bug when it's sends
some unknown token and think that it was revoked while it wasn't.
For example Google OAuth revocation endpoint implementation do not
follow the spec and returns 400 Bad Request with error message "Token
is revoked or expired".
4. token was already revoked
The same as above: this can be a bug in a client and we should return
400 status. In case of reference token which was removed from DB we
can't distinguish that the token was revoked or even existed so this
situation is the same as unknown token.
5. token type is unsupported
For this case specification introduces a new error code for case 5 in
section 2.2.1. Error Response :
unsupported_token_type: The authorization server does not support
the revocation of the presented token type. That is, the client
tried to revoke an access token on a server not supporting this
feature.
But it would be better to mention that revocation of ID token (which
can be is considered as "public" and not used to auth) definitely
should cause this error.
It would be great if we discuss this cases and improve specification.
P.S. Also it may be worse to mention that specification says that
content of successful response is empty but status code is 200 instead
of 201 "No Content".
Regards,
Sergey Ponomarev <http://www.linkedin.com/in/stokito>
_______________________________________________
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
