Re: [OAUTH-WG] OAuth 2.1: Missing token?

Neil Madden <neil.madden@forgerock.com> Fri, 04 February 2022 10:20 UTC

Return-Path: <neil.madden@forgerock.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 04C223A1440 for <oauth@ietfa.amsl.com>; Fri, 4 Feb 2022 02:20:10 -0800 (PST)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 SG29e7IpMa9V for <oauth@ietfa.amsl.com>; Fri, 4 Feb 2022 02:20:04 -0800 (PST)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 4E96B3A143D for <oauth@ietf.org>; Fri, 4 Feb 2022 02:20:04 -0800 (PST)
Received: by mail-ej1-x634.google.com with SMTP id h7so17953538ejf.1 for <oauth@ietf.org>; Fri, 04 Feb 2022 02:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hKt0qXnHVQZ4z+eUs7GI6FAIPcnz1/lkMtbDLY9TWJE=; b=NKmP7fkAA0TGIeyaFwl/yduEFx0OGIJ/lSaLB16YdfjnZTWecWJEa9yJ3djcDHflmr 3YSIxwGeLf6IAC/Pn3n5cDTC4/vtBoubLTPQazI9uk93fkllk6AvJISOh05GGzIi6G3z PIVUMDcHlsZx0kfFrT+Nnw3HTBIuaQSFi7QOc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hKt0qXnHVQZ4z+eUs7GI6FAIPcnz1/lkMtbDLY9TWJE=; b=jjPNVbKZSdC3OYGW7/bP1BDvr6spNC2lGZ/3FMt8jNsPK984YXyx1lnyjgBa44wM/4 9rpMIQOMnZ1F3zRxN4w1VfWMkw37T/ZptDu72z1VVI9gMwt0xSu/I1AxlKToqiV77bsA WU5OaYheG9uFPVNDq4cF0l75sBWFdtsXRpHQLAZcWNctTEgg+vXjw8nT9ZaydztvskcE 5KsyjwL6Izh5x3jjYMh8tC/XNBfWw46+ZzWOSEycIaPgLuPU/mTEGWzTPR3k0ka0PNWN i1gbmRA6IpeMaHuusqCaq8/eAEMz1o8zStxZ2qyYpw41cuNafjzSVyJW6ArSSpkVoa0j HkaQ==
X-Gm-Message-State: AOAM531JMIATPJTod0Uzncveiwx3a29BzsAggO5MxU7ov8NuFa+eOeSo t6BEAQ+a8/FYcbfZCQq/ga9Jnw==
X-Google-Smtp-Source: ABdhPJxyc/8gnAGpDK0TBWuxko11mYpfFaKnEPtsHhDUVkg3Nb+xeZIjxb6MANt5+Vie8GeVVxw6QQ==
X-Received: by 2002:a17:907:30d6:: with SMTP id vl22mr1795639ejb.453.1643970001253; Fri, 04 Feb 2022 02:20:01 -0800 (PST)
Received: from smtpclient.apple (78-33-22-162.static.enta.net. [78.33.22.162]) by smtp.gmail.com with ESMTPSA id z25sm638021edm.60.2022.02.04.02.20.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Feb 2022 02:20:00 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <3CA1894C-4B0F-4B14-9D83-35C87362A613@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52208766-B648-4A0B-8180-C215DA241652"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 04 Feb 2022 10:19:59 +0000
In-Reply-To: <CAGRquTpc0Un5igAdx_ftcMQvpGCEwxBNOjNL+dyk3D0EK9T3Jg@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Johannes Koch <johannes.koch=40avenga.com@dmarc.ietf.org>
References: <CAGRquTpc0Un5igAdx_ftcMQvpGCEwxBNOjNL+dyk3D0EK9T3Jg@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nWNGqhZjG14Yne7MykcZp50arb0>
Subject: Re: [OAUTH-WG] OAuth 2.1: Missing token?
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, 04 Feb 2022 10:20:10 -0000

The example at the end of section 5.2.2 suggests no error_code and just a 401/WWW-Authenticate header in this case:

 For example, in response to a protected resource request without
   authentication:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Bearer realm="example"


And the paragraph in section 5.2.3 immediately following the section you quote is even more explicit:

   If the request lacks any authentication information (e.g., the client
   was unaware that authentication is necessary or attempted using an
   unsupported authentication method), the resource server SHOULD NOT
   include an error code or other error information.

So, no error_code at all if no access token supplied.

Kind regards,

Neil

> On 4 Feb 2022, at 09:15, Johannes Koch <johannes.koch=40avenga.com@dmarc.ietf.org> wrote:
> 
> 	EntSec couldn't recognize this email as this is the first time you received an email from this sender johannes.koch=40avenga.com @ dmarc.ietf.org
> 
> Hi there,
> 
> a question about https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04>
> 5.2.3.  Error Codes
> 
>    "invalid_request":  The request is missing a required parameter,
>       includes an unsupported parameter or parameter value, repeats the
>       same parameter, uses more than one method for including an access
>       token, or is otherwise malformed.  The resource server SHOULD
>       respond with the HTTP 400 (Bad Request) status code.
> 
>    "invalid_token":  The access token provided is expired, revoked,
>       malformed, or invalid for other reasons.  The resource SHOULD
>       respond with the HTTP 401 (Unauthorized) status code.  The client
>       MAY request a new access token and retry the protected resource
>       request.
> 
> Now, what is the intended error code for the situation where no access token is provided? The description for invalid_token seems to imply that one token was provided.
> As the token may be seen as a required parameter, invalid_request may be appropriate. However, a missing token smells more like HTTP 401 (Unauthorized).
> 
> Should this be an additional error code (missing_token)? Or should this case be added to invalid_token?
> 
> -- 
> Johannes Koch
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth