Re: [OAUTH-WG] Token Revocation error codes

Sergey Ponomarev <stokito@gmail.com> Tue, 22 May 2018 15:19 UTC

Return-Path: <stokito@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF212711D for <oauth@ietfa.amsl.com>; Tue, 22 May 2018 08:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYlAtsGox77P for <oauth@ietfa.amsl.com>; Tue, 22 May 2018 08:19:24 -0700 (PDT)
Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5374412762F for <oauth@ietf.org>; Tue, 22 May 2018 08:19:23 -0700 (PDT)
Received: by mail-ot0-x22f.google.com with SMTP id t1-v6so21367810ott.13 for <oauth@ietf.org>; Tue, 22 May 2018 08:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QbA3ZhVw+YmL1QgMT2DigsgNnJzpqTGwN7gLmGvfRBs=; b=TtERmdjCGG4VBfk2BFcs4J2TtUshqQUf8BgxAHymx4moFkXzL4kkche7/ni8U3yzZN 0QZDiHIsNdi0+EAZ+THOkHIRvWtJV9StShOVYoVw6Tt54yECutjJ6mO2aaOMecy5mu1Y /eWg/1wwwqKfv8FOS6YFk5kkMIsr5DKXRYqh2wHK7atCNsMaGho0g1QTacQClwig9thz PnT3nqLqpuUNbDgO91chKkuxPNOVXjPgLd0jTRm/AoJVTqwaUOarX+ik+JmMeC3ckd9x cvOZ9ooNp0kGVCPRmmhieFNfAZQKwNklQDue1pgrgG6C9xjcaz7W1JvuG6nPnrSiJLiQ WeWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QbA3ZhVw+YmL1QgMT2DigsgNnJzpqTGwN7gLmGvfRBs=; b=PU5i8okW3Li09VJbtXz0N21Q4KJbDMRB1CMChlnRk3dcT6z6cVbURQLkgaQNhfSeMS oXCQyfCFcV0W3xfbDqRFG68luvAzT2kF8dG/OWIYpEkFZLOFla5tJxX16hz43lxqJsoa pTperYx3r5UXShng2J89oRccIndCxAsZb/EZEuormSHanriGcrVvh6+dCVyM/s28wY7f pqr1LI/XqCgpY15xnTrT163rZDcWizuIaF3wkKgHjaFg3Pa0Qh0pXuZFlTh0mkjulp9S 7xFKVrUAdLsrHhZ5sWC4K/aFQsLUc2USkP8P6Ay+K/wJ3q5y67HK3SSOdUlfLABHmydq vySw==
X-Gm-Message-State: ALKqPweOcJ5qmeaxwwE5JgVEM8c2TmEdTq0prhgNGANCFV0+uQdRKK9E S2voNHBgMMKJmQbSHFViVgxt3O15Pjrtm9wkeLQ=
X-Google-Smtp-Source: AB8JxZrgIw74JwdKJhU9q5ErGRr5YH9VIJM+O/QHhfaDKBoZ7dJuKlxRQBPpBe3HOS/DENEhonnYt1N5xwooBQwt6p8=
X-Received: by 2002:a9d:cc8:: with SMTP id o8-v6mr16830008otd.86.1527002362484; Tue, 22 May 2018 08:19:22 -0700 (PDT)
MIME-Version: 1.0
References: <CADR0UcWmKLmy=NcvCAH+6C2c55vgux1=z+7xpMHMApYLV-VQrw@mail.gmail.com> <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com> <CD52F9C3-EAED-48A5-BA0D-90B1D3F70811@mit.edu> <A13CFBFA-A94B-4095-9260-DEE61B359C56@authlete.com> <1241C308-15BA-4235-85B8-5B12E1E4B248@mit.edu> <CAEayHENcjk8rnya2ahNcG8BaZhg9=44s78iKaYoUBOnStpu33w@mail.gmail.com>
In-Reply-To: <CAEayHENcjk8rnya2ahNcG8BaZhg9=44s78iKaYoUBOnStpu33w@mail.gmail.com>
From: Sergey Ponomarev <stokito@gmail.com>
Date: Tue, 22 May 2018 18:18:46 +0300
Message-ID: <CADR0UcWAs2F21N+wEvMT82v44ue0iM7uPxDgXZLEE_=0zER-Kg@mail.gmail.com>
To: t.broyer@gmail.com
Cc: jricher@mit.edu, oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000631d04056cccf1ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/SBGuEesUyXE0xA5PrjWyjC2FF4s>
Subject: Re: [OAUTH-WG] Token Revocation error codes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 May 2018 15:19:28 -0000

>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 <t.broyer@gmail.com> 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 <jricher@mit.edu> 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 <joseph@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 <jricher@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.com@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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth <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
>>
>>
>> _______________________________________________
>> 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
>


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