Re: [OAUTH-WG] Token Revocation error codes

[Sergey Ponomarev <[e-mail]>]

What is also should be discussed and specified is revoking of expired
token. For example in Keycloak you can invalidate a session by expired
token:

> It should be possible to logout a session with a token that is expired.
> This is to make sure that a user can invalidate a session if there's a
> suspicion that the refresh/offline token has been leaked. In such a case it
> could be that the real user has an expired refresh token while an attacker
> has been able to refresh the token and obtain a new not expired refresh
> token.


KEYCLOAK-3302 <https://issues.jboss.org/browse/KEYCLOAK-3302>

Think this is doubtful but makes sense.

To summarize: we have to create some threat model with description of
possible use cases.


On Tue, 22 May 2018 at 18:18, Sergey Ponomarev <[e-mail]> wrote:

> From OAuth perspective we can't say that the token should have some
> structure: they can be any random value in case of reference (opaque)
> tokens. But the Google's OAuth Server responds in this case with 400 error
> "invalid_token".
> The same can be used for JWTs with invalid sign or issuer.
> So it would be better if specification allow OAuth servers to respond with
> this error code if it clearly know that token was invalid by format.
>
> On Tue, 22 May 2018 at 17:51, Thomas Broyer <[e-mail]> wrote:
>
>> IFF the server processes it!
>> RFC 7009 says “An authorization server MAY ignore this parameter,
>> particularly if it is able to detect the token type automatically.” which
>> BTW is exactly my case.
>>
>> For months, my AS received requests with token=Array, and now receives
>> requests with token=null. Those are clearly bugs in the client code, and
>> because I return a 200 OK, the developers aren't aware of it.
>>
>> If tokens have an expected "structure", I think AS should probably return
>> an error when the token value clearly is not a token (at one point I may
>> change my implementation to do just that). As soon as it looks like a
>> potential token though, then 200 OK sounds good to me.
>>
>> On Tue, May 22, 2018 at 4:34 PM Justin Richer <[e-mail]> wrote:
>>
>>> In that specific case, the token_type_hint value is invalid and can be
>>> rejected as an invalid_request.
>>>
>>>  — Justin
>>>
>>>
>>> On May 22, 2018, at 5:27 AM, Joseph Heenan <[e-mail]> wrote:
>>>
>>>
>>> I think one important point Sergey raised was that the response to the
>>> client from submitting the wrong token is the same 200 response as
>>> submitting a valid token, and that hugely increases the chance that the
>>> developer of the client app might submit the wrong token and never realise.
>>> Making it easier for the developer of the client app to see that they've
>>> done something wrong and need to fix their implementation seems like a
>>> worthwhile goal to me, and that would appear to explain what google are
>>> thinking with their responses.
>>>
>>> An example of an easy to make error that would get a 200 response is
>>> getting the values the wrong way around, i.e. a body of:
>>>
>>>      token=refresh_token&token_type_hint=45ghiukldjahdnhzdauz
>>>
>>> (as token_type_hint may be ignored by the server.)
>>>
>>> The example Sergey gave of the developer accidentally sending the id
>>> token instead of the intended token seems quite likely to happen in the
>>> real world too, and a 200 response in that case does seem wrong to me.
>>>
>>>
>>> Joseph
>>>
>>>
>>> On 21 May 2018, at 22:29, Justin Richer <[e-mail]> wrote:
>>>
>>> I’m with George here: revocation is almost a best-effort request from
>>> the client’s perspective. It sends a message to the server saying “hey I’m
>>> done with this token, you can throw it out too”. If the server does revoke
>>> the token, the client throws it out. If the server doesn’t revoke the
>>> token? Then the client still throws it out. Either way the results from the
>>> client’s perspective are the same: it’s already decided that it’s done with
>>> the token before it talks to the server. It’s an optional cleanup step in
>>> most  OAuth systems.
>>>
>>>  — Justin
>>>
>>> On May 21, 2018, at 5:08 PM, George Fletcher <
>>> gffletch=[e-mail]> wrote:
>>>
>>> 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 even unknown
>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://www..ietf.org/mailman/listinfo/oauth>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito
>


-- 
Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito