From sachinmamoru@gmail.com Mon Feb 19 22:44:25 2024 Return-Path: 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 D51BEC14F6F0 for ; Mon, 19 Feb 2024 22:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGD64j_-zshb for ; Mon, 19 Feb 2024 22:44:21 -0800 (PST) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727BAC14F69E for ; Mon, 19 Feb 2024 22:44:21 -0800 (PST) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-6081bc96387so18830227b3.0 for ; Mon, 19 Feb 2024 22:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708411460; x=1709016260; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=hDAC+sTE3co8OwgW2OzDiuEeJ8j0yYpEtgeYqhkLmwQ=; b=gFUZtwLF5uowgp9hSMSFPFvJklcaAtfqwpr0jymOO6DQ/0H/KUaV2oddpTAbZfnXyv aY3FG7QYdwVOlxQiZT/lECCU6xy2uh66vrA7OFJO8cVXpjaoVJCLcviT1fyg5unQD9v0 7exV6ZMklqF9Ian8RfnBlzbhgB49xBM7kH+qt8ty2RQ1ChGH22qF7Y1N5jpUFm9Pntbf AsqlOICeggrGeO7C2UNG7qfYl+4SnBQjvNd+GtzgB4zaUW/OXyKU27Lo0QEHBOH7v83K n4KUT2kiz2V27hcR6HG87dlbsZdlv48E5z42wB2ObZKWA4hRQdkFzYVPnA53Ory+js/2 TgyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708411460; x=1709016260; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hDAC+sTE3co8OwgW2OzDiuEeJ8j0yYpEtgeYqhkLmwQ=; b=j1E/E7AMh3ifdBKTSmAwkZ0q0keXz76aR6ZS5feTzqczZl6tFldxj74HN/ZUUwfm95 Ld3inV/db10siH/Y5G5/FNzKZg6rC0CelSPB10N1sleTJrUzmVnTw5gaN5fN2X6uD+1z F5UR6MgBT9dtbiZKwTDDRkcfhCXAqWRdgcb68ef3Z/PYhISd00gktVHkR0pkL3DSjJFI 2M8Tv2UQwaZtU7CwpXwIvOk+xhnn69/Op80DjnPTBpHPs1Bu/JwdlryAKJVjOGku7Ou8 blE0y6itX9bN0du+jqPt8efoIQvwb69Yzam407IhiwgmKCqGgyUvJBEIDlphAiYzxdjB pA+Q== X-Gm-Message-State: AOJu0Yz/y0f5wiWcRbsjmqyviG+gkMqaUWAQg7u2Cb/ErGi+LEoI8Otn twt481o3ntgIRINvQQhBy6oi2mUzbGzmSYWXXKH/41QwIpoOpT46fOi5xeL3Q6g79Krz0rHdlbV OAIOxAfFFLQN+V6pNXB94IHzzuxtnx2/2BOyJQ1XC X-Google-Smtp-Source: AGHT+IHswqeBUAbE9j9WTvFpcFmSj8d1X1YjXG4n+Sh6WxLA7m6TwWuBdoIUTNsHIuRzeekBvkM/Uhwf5G+SOjliTGY= X-Received: by 2002:a5b:5c2:0:b0:dc6:1869:9919 with SMTP id w2-20020a5b05c2000000b00dc618699919mr14552615ybp.41.1708411459931; Mon, 19 Feb 2024 22:44:19 -0800 (PST) MIME-Version: 1.0 From: Sachin Mamoru Date: Tue, 20 Feb 2024 12:14:08 +0530 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000003310a00611ca8a8c" Archived-At: Subject: [OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2024 06:44:25 -0000 --0000000000003310a00611ca8a8c Content-Type: text/plain; charset="UTF-8" Hi All, When we request an access token using 3 scopes (scope1, scope2, scope3). Then will receive a refresh token (refresh_token1) with the access token. After that will request another access token with refresh_token1 and provide the scope list as scope1 and scope2 (Narrow down scopes). Similarly, get another refresh token (refresh_token2) with the access token. Now if we request another access token with refresh_token2, we cannot request scope3, instead, we can either request both scope1 and scope2 or one of them. But in the specification, didn't able to find anything related to narrow-down scopes with refresh token. >From Spec 1.5. Refresh Token - Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). 6. Refreshing an Access Token The scope of the access request as described by Section 3.3. The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner. https://datatracker.ietf.org/doc/html/rfc6749 IMO, from a security aspect, the current behaviour is much more secure because it is designed to maintain the principle of least privilege, where it updates the refresh token authorised scopes based on the requested ones. What should be the correct behaviour? narrow-down scope refresh token should also be able to request access token with original scope list? Your input is highly valuable on this. Thanks & Regards, Sachin -- Sachin Mamoru Software Engineer, WSO2 +94771292681 | sachinmamoru.me sachinmamoru@gmail.com --0000000000003310a00611ca8a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

When we request an access token using 3 scopes (= scope1, scope2, scope3).

Then will receive a refresh token (refresh_token1)= with the access token.

<= br>

After t= hat will request another access token with refresh_token1 and provide the s= cope list as scope1 and scope2 (Narrow down scopes).

Similarly, get another= refresh token (refresh_token2) with the access token.


Now if we request another access token with refresh= _token2, we cannot request scope3, instead, we can either request both scop= e1 and scope2 or one of them.


But in the specification, didn't able to find anything related to na= rrow-down scopes with refresh token.


From Spec


1.5.=C2=A0 Refresh Token -=C2=A0Refresh tokens are issued to the= client by the authorization server and are=C2=A0used to obtain a new access toke= n when the current access token=C2=A0becomes invalid or expires or to obtain addi= tional access tokens=C2=A0with identical or narrower scope (access tokens may hav= e a shorter=C2=A0lifetime and fewer permissions than authorized by the resource= =C2=A0= owner).


6.=C2=A0 Refreshing an = Access Token

The scope of the access request as described by=C2=A0= Section 3.3.= =C2=A0 The requested scope MUST NOT include any scope=C2=A0not originally granted= by the resource owner, and if omitted is=C2=A0treated as equal to the scope orig= inally granted by the=C2=A0resource owner.


https://datatracke= r.ietf.org/doc/html/rfc6749


IMO, from a security a= spect, the current behaviour is much more secure because it is designed to = maintain the principle of least privilege, where it updates the refresh tok= en authorised scopes based on the requested ones.


What sh= ould be the correct behaviour?
narrow-down scope refresh token should al= so be able to request access token with original scope list?


Your input is highly valuable on thi= s.


Thanks & Regards,
Sachin

--
=C2=A0
Sachin Mamoru
Software Engineer, WSO2
+94771292681
| sachinmamoru.me=C2=A0
<= tr>
sachinmamoru@gmail.com=C2=A0
= =

3D"" --0000000000003310a00611ca8a8c--