Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
Vittorio Bertocci <vittorio.bertocci@auth0.com> Fri, 03 April 2020 06:46 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 65CBB3A10C2 for <oauth@ietfa.amsl.com>; Thu, 2 Apr 2020 23:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 CUrCcy64OUJs for <oauth@ietfa.amsl.com>; Thu, 2 Apr 2020 23:46:06 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 331943A10BF for <oauth@ietf.org>; Thu, 2 Apr 2020 23:46:06 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id c23so3070601pgj.3 for <oauth@ietf.org>; Thu, 02 Apr 2020 23:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=8zKNVBtqvHEUjWuKSITB2eqtM6LQnXZsCvcL3IRoAAw=; b=iCZAqem6CaciaJ2YWN/jB5HAwsi5TgGxvNulAWyM2c0bTfWGIthVILy9ZDv4Vd0ypM qavelnf+CBw0ULveCsSM5tqdTr4saBL2puStPdslywmxn8EdxRp+bNjZZCh0uqG0AZVT KYA06tYrsLhPFB/7J6EBvDu1y1ldydGesjkbJ3lEvCxGYs0WpPDmG5ElxfVod0AVGDW1 71jExDvW8D5mZFmQDmzluCimWzLtMGTYrN1GFoF/AZFsr1tJRKNGo8OXrREIjk8urkeA huqLq9mYMlNBpArqx0J1Yg3zis0HP4Uh4LXBepUCRkooE+65pZs41rjobfyPCV7v1Jtx 00EQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=8zKNVBtqvHEUjWuKSITB2eqtM6LQnXZsCvcL3IRoAAw=; b=o8509K7Wpup6X3vbWlucH1oNgnGbSHSC1MKL2Kh2wNCNc4PFC9cE+fTDMNpt302k7p s79UcYUG22UadNSXJxRJ9VhpFZ/0ksles544Wj4m6mnJZpytX4/wo8s0DtfdJsvOTgPL 2vmTGdLgHno+/X3L68eVaw/avZbQM+Wr6RJAOPSF2CCsrX4rvj+88KpsebzP5a811XVq YHFInOsLO3nG0SYyZOTO5dj3uFb91qPZLd5tvY1vfRNWleEosRVDAOuLsOTwDQnP+Bhx MLqU2oY6QSC2EjPXqEyaPVU8e/FHEso+Jq1q1lh3xn3ce4wV9kVaHPHxOuJ3KdAqjb84 TY6A==
X-Gm-Message-State: AGi0PuZ0Rk4WU50sGtSBfnpANcV1pjQP6QpTasU1WUzTlcg+hueHlleM qBcTzqFVoZgUCYLkGKuFHepcEg==
X-Google-Smtp-Source: APiQypKwKGHWOykGY1pTd94qshb6iGuTgRa1MVdMd/pcFbY5ehjZtEW5jfcfKJCOUMj43yjTcW6B1g==
X-Received: by 2002:a63:a351:: with SMTP id v17mr6646388pgn.319.1585896365208; Thu, 02 Apr 2020 23:46:05 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id 1sm5062767pjo.10.2020.04.02.23.46.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 23:46:04 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: Karl McGuinness <kmcguinness=40okta.com@dmarc.ietf.org>
CC: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
Thread-Index: AWc2c3hjpw0LjVgh/3UrGwXW8Y7ysiRkNCRkMUNCNDLa+ORwRA==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 03 Apr 2020 06:46:03 +0000
Message-ID: <MWHPR19MB150194FA38AD91F0B64D8621AEC70@MWHPR19MB1501.namprd19.prod.outlook.com>
References: <CAGBSGjrzYcLaHY3n01rxpaYvDMiM1s9fdbpC6Wj67F7p7kex6g@mail.gmail.com> <13cbd01d602df$f19f7490$d4de5db0$@auth0.com> <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com>
In-Reply-To: <90853492-D222-463A-9DB0-BA0EC82826B1@okta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB150194FA38AD91F0B64D8621AEC70MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/59Vea2ZVheL0Nt-haQXKaapTOwk>
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: Fri, 03 Apr 2020 06:46:09 -0000
Hi Karl, Thanks for the comment. I agree that having a framework for further clarifying authentication assurance would allow SDK owner to provide even more functionality out of the box. I also agree that the definition of such a framework for authentication assurance goes beyond the scope of the current profile. Nonetheless, defining in tis profile what claims should be used for carry that information isn’t without interop value, as it discourages the introduction of different claims to carry that info and at least helps SDKs to identify those claims in the incoming tokens and expose their values their object model/events collection, saving the end developer at least some work; and if more guidance about the values of those claims will eventually emerge, it will be easier to dovetail further SDK logic downstream than if we would have left even the transport claims entirely unspecified. Thanks V. PS: if you want to draft such a spec, I am sure there would be interest in reviewing it 😊 From: Karl McGuinness <kmcguinness=40okta.com@dmarc.ietf.org> Date: Monday, March 30, 2020 at 09:38 To: "vittorio.bertocci=40auth0.com@dmarc.ietf.org" <vittorio.bertocci@auth0.com> Cc: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org> Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens Hi Vittorio, I was chatting with Aaron offline about this issue and my concern is the addition of Authentication Information Claims in this spec opens up more interoperability issues that can’t be addressed with just a JWT Access Token spec. OAuth 2.0 AFAIK, doesn’t define any behaviors around resource owner authentication assurance with respect to issuing, introspecting, or presenting access tokens. * Token introspection * Token validation error responses * Token refresh * Client Remediation (oidc defined prompt=login, max_age, and acr_values) * Metadata This spec is defining AS behaviors that are orthogonal to the format and should be available via token introspection for example https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1 The claims listed in this section reflect in the access token the the types and strength of authentication that the authentication server enforced prior to returning the authorization response to the client. Their values are fixed, and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token, or exchanging one access token for another via [RFC8693<https://tools.ietf.org/html/rfc8693>]). I was hoping one of the outcomes of this spec was toolkit/sdk interop for clients and resource servers. I don’t see how this possible if all the semantics around requesting, validating, and remediating resource owner authentication assurance is implementation specific. The end-to-end scenarios are not achievable with just OAuth 2.0 which breaks interop. I think there is a real need to define resource owner authentication assurance interoperability for access tokens, but I fear this may require its own spec. -Karl Karl McGuinness Chief Product Architect www.okta.com<http://www.okta.com/> On Mar 25, 2020, at 12:59 PM, vittorio.bertocci=40auth0.com@dmarc.ietf.org<mailto:vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote: This message originated outside your organization. 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<mailto:oauth-bounces@ietf.org>> On Behalf Of Aaron Parecki Sent: Wednesday, March 25, 2020 12:07 PM To: OAuth WG <oauth@ietf.org<mailto: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 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