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 <jos...@authlete.com> 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 <jric...@mit.edu >> <mailto:jric...@mit.edu>> 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=40aol....@dmarc.ietf.org >>> <mailto:gffletch=40aol....@dmarc.ietf.org>> 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 list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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
