Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens

[Karl McGuinness <[e-mail]>]

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=[e-mail]<mailto:vittorio.bertocci=[e-mail]> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Aaron Parecki
Sent: Wednesday, March 25, 2020 12:07 PM
To: OAuth WG <[e-mail]<mailto:[e-mail]>>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth