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

Vittorio Bertocci <> Tue, 31 March 2020 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC1BC3A09A2 for <>; Tue, 31 Mar 2020 14:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OJNYzlcBa-gk for <>; Tue, 31 Mar 2020 14:34:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7977C3A094B for <>; Tue, 31 Mar 2020 14:33:58 -0700 (PDT)
Received: by with SMTP id c12so5850924plz.2 for <>; Tue, 31 Mar 2020 14:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=H23OY+Z1VeP7RHi3WPVZMmz0z9nxMnZvuHZ2z0Jgk1Y=; b=O9/hHIl0yyjmMdvEsD0fgl5WQWdFr/Mp1U+4HHbKjB1+xA3aSRdeYbcyXJq6YkIvLg PMsGopcj58XHZyO7odyWmA4ceEIu8YfCWCNPrOA8RCsydXyaKoZZjZqNhR8l2QeJVIKS CpiU//DbeZh08trqJmKb83V+3YrW02zvu4Q4Lg5Oia7rrLoBbRa1yKhzu4Xgu99nOhbV nqgRUr0SYQgIJXI01+1/MvES7t1ulZ1bvNWsYbCoopqO9n3r4cYb9JPLl2yDVcCdt7Uw jjn4Ni8I56o5ezUbTxScPlJpdaKeEKKT3HC1jQylk1XtdZBbn0MpzyJCikyvQtWVeY+j +BBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=H23OY+Z1VeP7RHi3WPVZMmz0z9nxMnZvuHZ2z0Jgk1Y=; b=HX3W3G+jubl4YWHQJsXZcXc5vYvO4G+cWcQCtiTcHeZFC9T44zZO6jhGUdHk3XW767 D0I7Xo8jaNllyicczwv/dqca+Xy+70ZVM2TRpR/A8Xh/DJEcNmc5Ps0Avi+DVCxLSnuc mK8QGTo6T7qPkYVLUYTLOhYItxaVbzRqQuAtumkxiavkyunP//wLa22mP8tzUDdkfP+0 18VayUpoErBRlCKaYIIVTJo5Bn0zAWABctYaWhnPk5PN/L4IU/T8sWJBb3SpcyZ+c2oo Q1f1AaRhgGeDXvuecGYHHSa73XzVBsV1EcciajCeilSe1blGw2uPQ9nceU9fRFdV3VCA tS/w==
X-Gm-Message-State: AGi0PuarhOP7IlV8KvvzgxH8rZX/gzoy6ddIfVlZ0GFvA1RHUiW5zIiD 5xLdMeGY/ez8FnwYLXBSm1AavQ==
X-Google-Smtp-Source: APiQypLKWRaFK1rlNUB8irllIhAtmn4xishTfJk3VGKjxhYTu92y2PazBg4ClaLvS/zrmLjuy3cZKQ==
X-Received: by 2002:a17:90a:198b:: with SMTP id 11mr1044709pji.23.1585690437592; Tue, 31 Mar 2020 14:33:57 -0700 (PDT)
Received: from ([2603:1036:120:1d::5]) by with ESMTPSA id 67sm74167pfe.168.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2020 14:33:57 -0700 (PDT)
From: Vittorio Bertocci <>
To: 'Aaron Parecki' <>, 'OAuth WG' <>
Thread-Topic: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
Thread-Index: AWc2c3hjpw0LjVgh/3UrGwXW8Y7ysiRkNCRk3H8/lxA=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 31 Mar 2020 21:33:56 +0000
Message-ID: <>
References: <> <13cbd01d602df$f19f7490$d4de5db0$>
In-Reply-To: <13cbd01d602df$f19f7490$d4de5db0$>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2020 21:34:09 -0000

Alrighty. I added language to explicitly call out 6570 and invalid_token... and eliminated step 7 in the validation for other reasons, indirectly obviating for the need to clarify the reauthentication signaling mechanism.
Updating the draft shortly.

On 3/25/20, 12:59, "" <> wrote:

    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
    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_.
    -----Original Message-----
    From: OAuth <> On Behalf Of Aaron Parecki
    Sent: Wednesday, March 25, 2020 12:07 PM
    To: OAuth WG <>
    Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access
    Section 4 talks about validating JWT Access Tokens
    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
    OAuth mailing list