Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
vittorio.bertocci@auth0.com Wed, 25 March 2020 20:00 UTC
Return-Path: <vittorio.bertocci@auth0.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 3FC423A0DD2 for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 13:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=auth0.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 2qkQHuijStrn for <oauth@ietfa.amsl.com>; Wed, 25 Mar 2020 13:00:54 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 E65763A0C9A for <oauth@ietf.org>; Wed, 25 Mar 2020 12:59:51 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id h72so1591164pfe.4 for <oauth@ietf.org>; Wed, 25 Mar 2020 12:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Nrgp5pr3DplQMZHtXsopxisFPOCf5Ib/1aOdSKNkqlU=; b=RbsE+C5O7Pgkz+y5hfdcf1raww6Rd0OJjGSegT94qD4TpI1Frvy6yut6SVHyvNFjLo HGpD8sj5qnrFSAk6nEVOg2NQ+ODRj0LBcsb9lEc7ceIv7OVFEovf8zwC67+bllKdtM+R WmXz43XAOR0sgXGtePohg2UnnrmqaBQ4dsnFYFeSzgQQFnTQKLqzyVHFO+QDxIcUUUA5 WJ5F7ONbJ82YYz4PKj1MCK0UpbNVtFK7TfD/cO2AnHX7cXdHqAxA/7GsXnyRRUFzv/uL 89TGLNKC/FhT88yFvr8i00dPQAIWG3hmnCuoAlfDw/7qNufcYS5qEwhMbuv74PcUPNYh QS5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Nrgp5pr3DplQMZHtXsopxisFPOCf5Ib/1aOdSKNkqlU=; b=tRaYXc26lzNkgCyIMMQzm4tiy81xmJ5ZXBcQTJ2waM6RI7sZXN0J7MVWEPdHmMnaDP kbDxkcyaXACeLWsvuf6LrxAyiyEFKXJpvABX4T3DNJLwEmAEuyFt05/H0wrty273I4Zx dErPR8NkGHlBxnxghyphWX8XxYHIKTCPgXheFrGiEx+cbqRdIliN91xwGodaqTJ4DNTG ztUfuWgTccuCvYFXfC/NZVcxgKC7Eme+jooW2HLiDTgsjUIU8CXhiI6/byreIRJ9ZGkm M9ayCXnTn8DvnR5iHRt9C9CZO1FMVLmr8X4YtkxXONKRfRCzUUDVxjetG2vAZW4HNTGe o9bw==
X-Gm-Message-State: ANhLgQ26C6sFUZJrc2dhLqedMnoehfilwGyhgQQo72cpo+MqS350/jMe 9iJxgAYGSp3aAkcHiPP6jRJqMA==
X-Google-Smtp-Source: ADFU+vvZCYKmeHiMDu3O/YnKzgJSEj6KAXnqdy3K9lqb/ZR+Ey8ujuHqiD1N3dks5u+P1plYyKU2Rw==
X-Received: by 2002:a63:91c1:: with SMTP id l184mr4575910pge.341.1585166390715; Wed, 25 Mar 2020 12:59:50 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id h4sm19208954pfg.177.2020.03.25.12.59.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 12:59:50 -0700 (PDT)
From: vittorio.bertocci@auth0.com
To: 'Aaron Parecki' <aaron@parecki.com>, 'OAuth WG' <oauth@ietf.org>
References: <CAGBSGjrzYcLaHY3n01rxpaYvDMiM1s9fdbpC6Wj67F7p7kex6g@mail.gmail.com>
In-Reply-To: <CAGBSGjrzYcLaHY3n01rxpaYvDMiM1s9fdbpC6Wj67F7p7kex6g@mail.gmail.com>
Date: Wed, 25 Mar 2020 12:59:50 -0700
Message-ID: <13cbd01d602df$f19f7490$d4de5db0$@auth0.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKMAdkbjQsNpyFYdf8rGwXW8Y7ysqbtsSpg
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cJIRWOQRzCpjmV9sDEJTVmWY3TU>
Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 25 Mar 2020 20:01:00 -0000
Thanks Aaron! You are right, we could be clearer re:errors. AFAIK the only errors we can rely on from an RS are in RFC6750, and the entire section is about what to look for in an incoming AT to validate, hence it doesn't look like we have much choice but to return invalid_token for every error in the validation checks enumerated in Section 4. I can definitely add a paragraph to that effect (does it have to be a section?). The re-authentication part is tricky. Technically we are still rejecting the incoming token, hence the above should still apply. I am not aware of tools we can use from the primitives defined in the OAuth2 family of standards for telling people how to make reauthentication happen- and making reauth happen can be quite involved. In Azure AD there are semi proprietary mechanisms that can be used to signal the need to repeat authentication, say for triggering a step-up auth, by sending back together with the error response a challenge that can in turn be used by the client to communicate policy requirements to the AS (which is assumed to support OIDC and accept/understand those policies in form of claim). Giving equivalent guidance but relying only on standards seems tricky, especially without making strong assumptions about how auth happens (e.g can we assume OIDC?). To solve this for the profile, I see two main ways forward: A) We warn the reader that it's on them to decide how to signal the reauth requirement from the API to the client, and how to use that in the client to AS subsequent authorization request B) We venture in devising a standard mechanism for propagating errors that require reauth, basically extending RFC6750 with a new use case (perhaps by detailing extra info to be put in WWW-Authenticate?). I can see how B) might be useful in general, but it doesn't seem particularly tied to the fact that the ATs being discussed here are JWTs... hence I'd be inclined to declare it out of scope here, tho I would really love for us to devise a standard solution for it _somewhere_. WDYT? -----Original Message----- From: OAuth <oauth-bounces@ietf.org> On Behalf Of Aaron Parecki Sent: Wednesday, March 25, 2020 12:07 PM To: OAuth WG <oauth@ietf.org> Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens Section 4 talks about validating JWT Access Tokens https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-4 It has a list of things the RS MUST do when validating a request made with a JWT access token. This section contains phrases like "...and reject tokens..." and "MUST be rejected if...", without clear instructions on *how* to reject this request. For these, I could infer that the RFC6750 error code "invalid_token" is the correct response, but these could benefit from being more explicit about that here. Step 7 says: "the resource server SHOULD check the auth_time value and request re-authentication..." But there are no instructions on how the RS should respond to indicate that the client should request re-authentication. This sounds like a different response than "invalid_token" to me, but in any case, regardless of what the correct response is, Section 4 really needs a description of how to respond in these error cases. ---- Aaron Parecki aaronparecki.com @aaronpk _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Error Responses in JWT Profile for OAu… Aaron Parecki
- Re: [OAUTH-WG] Error Responses in JWT Profile for… vittorio.bertocci
- Re: [OAUTH-WG] Error Responses in JWT Profile for… Karl McGuinness
- Re: [OAUTH-WG] Error Responses in JWT Profile for… Vittorio Bertocci
- Re: [OAUTH-WG] Error Responses in JWT Profile for… Vittorio Bertocci