Re: [OAUTH-WG] Token Revocation error codes

George Fletcher <gffletch@aol.com> Mon, 21 May 2018 21:09 UTC

Return-Path: <gffletch@aol.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 3EE231289B0 for <oauth@ietfa.amsl.com>; Mon, 21 May 2018 14:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 NAcSA4YTIPGx for <oauth@ietfa.amsl.com>; Mon, 21 May 2018 14:09:00 -0700 (PDT)
Received: from sonic316-14.consmr.mail.bf2.yahoo.com (sonic316-14.consmr.mail.bf2.yahoo.com [74.6.130.124]) (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 3EFE6128896 for <oauth@ietf.org>; Mon, 21 May 2018 14:09:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1526936939; bh=/3+l8hMF6EPCA74CSRNnBjOB4eIO5SX4Z/ubGNYMaBM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ABNkRwGpyNvF6ONgPK/7a8yPNggOlIqMNmeIuynJ+tGp9nC2iSV2CD6fVFVFPkRsQSVRtz/IbtshKlOCMmomhPQUVoWHSA+tz1K5tSaj08nCibrbBzGfhR6kzroidE1sVZ4yJK85a8Xp0RdpEAPHzLDXJkWG/p0myO5QFvUwLrl/09ca+5zc3BBlsjeQ1M2KTz8/KCM68TglPuxc7qbsC12NMPvAUBmBHSaEsMN0rsHtmeny2DBBxwsBtS9O7PxlfKTK08n34gKoI9jyQ2Aop3bbGS84f6AR1kUzYwx/YjN5afyc22QXwTnctr7bNeXtMoM8uZftJOEPV7KJGzVNYA==
X-YMail-OSG: F0LoGj8VM1mf6ZszhOdyGJPyF0GTvJr6kLeDumOh4cTpD7Ac7VFnvFQwdd3R3sE .T72swRbHkSf2tsJDy6_XkfgM5xCXqdu7fFol5iAnVSirqpJQ7CP7nouvkQNhhaaQfvfdeZoBk8n DFx3v6VRIL9UNHKO21pnKUTvng8B7KjuTsqatT4.88D9hyzbq.Z3JMxzRO9vBBG1lcJoBtAkkus1 Of.eqI_b_kr9RqNrK5V9hExCGC3q.eQwbFqUsDH7mszIQtAx4bDqxEBXaAulMcv.seM4iGDSh8ZN iF4Wu2wWJCrpH_TrQ8LAW0C1ugcs5kDrKbsLxNHLLBUViJ43APcL1z.SKZsIN4wdLmT.5GrBp3iv F7ln0NET.HXSAoRcUaaAvZ40NsO894IBxKvhHvOgXnvUJ2Z7x5AFbakXUizqRYpV6ceWsQh7k3fq FTxfBdB9.yRdFcqK_KdKcjwtYnDyneIGCBVdH3.8EWBJYNJ2VG2p_JstuFNNDn4sEqByl6XQrCb7 craXjqeMvb9gI__pb7DDaYt0UEyJ21pwPlR7XXaOyLD9e8up9azpJnwuZQIlQvLAV6yqay3kA9I8 FaTuFCBxTr_9JZjz0GSgDgbqKvg1uAqKYjzztUgrFIdYVcDFg4b_VXrMa8yFM3vx0IuUJO6.s4OD OTzt_213J
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 21 May 2018 21:08:59 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 44129339f78e547e3547304483393148; Mon, 21 May 2018 21:08:56 +0000 (UTC)
To: Sergey Ponomarev <stokito@gmail.com>, oauth@ietf.org
References: <CADR0UcWmKLmy=NcvCAH+6C2c55vgux1=z+7xpMHMApYLV-VQrw@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <06748dd8-017d-81cc-1b2f-0aa9d61a4731@aol.com>
Date: Mon, 21 May 2018 17:08:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CADR0UcWmKLmy=NcvCAH+6C2c55vgux1=z+7xpMHMApYLV-VQrw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4C15641529AD713F172C421F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/l6A3RQxothFAx41_J9yz-NrmAJs>
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: Mon, 21 May 2018 21:09:03 -0000

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