Re: [OAUTH-WG] Token Revocation error codes

[Warren Parad <[e-mail]>]

According to RFC7009, I don't see anywhere which says you have to return a
200 for token=null. I interpret it as you return a 200, if the token passed
would never have been accepted as a valid token. *Null* isn't an invalid
token, it is an invalid value for the *token* parameter which is required.

   token   REQUIRED.  The token that the client wants to get revoked.


So the correct response is either an error immediately (returning a 4XX),
or feel free to return the 200 and then the AS should redirect the user to
a verified location with the *error *and *error_description* query
parameters.

I do see some gray area for what to do with real invalid tokens, i.e. the
token signature is invalid. So some clarity on the definition of
*invalid. *Since
the spec talks about invalidation lots of times we should interpret it to
mean *a token that has already been invalidated.* And I would interpret all
other tokens as justifications for returning a 4XX status code.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Wed, Jan 26, 2022 at 6:44 PM Sergey Ponomarev <[e-mail]> wrote:

> Hi and sorry for raising the four years old topic.
>
> As a recup I reported a SECURITY VULNERABILITY on OAuth 2
> specification level. It's minor (I hope) but still seen in the real
> world AS implementation.
> In short, to logout a user the revocation endpoint is called with the
> user's token. And by a the RFC7009 the AS must always return 200 Ok
> status code even if the token is invalid:
>
> > 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.
>
> So if a client just made an incorrect call e.g. token=null then it
> will anyway receive a 200 OK and the user will think that logout was
> successful and a session closed. But internally the token may be
> stored in many places and even shared  between microservices/UI and
> other parties and it will remain still working.
>
> Can anybody take some actions and at least make some errata to the spec?
>
> P.S. adding to CC authors of the spec
>
> On Tue, 22 May 2018 at 20:29, Sergey Ponomarev <[e-mail]> wrote:
> >
> > 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
> >
> > 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  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
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >> --
> >> Sergey Ponomarev, skype:stokito
> >
> >
> >
> > --
> > Sergey Ponomarev, skype:stokito
>
>
>
> --
> Sergey Ponomarev,
> stokito.com
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>