[OAUTH-WG] Evaluation of Scope Management in Refresh Token Behavior

Sachin Mamoru <sachinmamoru@gmail.com> Tue, 20 February 2024 06:35 UTC

Return-Path: <sachinmamoru@gmail.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 0336DC15108D for <oauth@ietfa.amsl.com>; Mon, 19 Feb 2024 22:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level:
X-Spam-Status: No, score=-2.085 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_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 YSdOa2kgII-U for <oauth@ietfa.amsl.com>; Mon, 19 Feb 2024 22:35:50 -0800 (PST)
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 DE8B9C15108C for <oauth@ietf.org>; Mon, 19 Feb 2024 22:35:50 -0800 (PST)
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-607e54b6cf5so30355777b3.0 for <oauth@ietf.org>; Mon, 19 Feb 2024 22:35:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708410949; x=1709015749; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9lXvgIhhhCQs+v0ldahLtFEK3sSCZmtkCR9fZ4U2dIM=; b=RqA5a/YNpqV9EPePziUyQR7mEs8cdEpH1YuJ2AvOiF/HMhUX0OLgxxrWC/837Z7+OF rxPxjgKvhiwQ2yv2zhzfrLrDjR0IJCVl59KMTZPRAXoPADlG5Apjq8Ats/HOGnhUqKm7 SjUBnAF+dfkiHzAUkkSISLr2k55BGJZNQLLyhbd1lR/Qfh+FF65AceOQSwm1XvVxf42o 36SPyOmflE+BtvLA8h2R4C9icBEtmpKU4m9xGD9dZS6t2coAUAqsGL4dqTg1yP2g0kur +m2ViNIVofcR/R5cmZiiBFagPdc5AvQQTvtMEYftSxWn25c5IvglvJX5xs1ZIcBg9KDq 3GeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708410949; x=1709015749; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9lXvgIhhhCQs+v0ldahLtFEK3sSCZmtkCR9fZ4U2dIM=; b=ViiIwQgY23l+TrZ1wIf/NSPOjzCPQQEbK6NIgy4QFrgBeYp4EIjI2TNXSr1mgsP4f6 B0cCCqKQcInHk1DlsmVNcVScILPit4PW4O29DIa84xrTCDCYtMZeEQq3eEKboHHEg+lM fRtaTZZx1vN9N0Z42nfbR+SarkQjqGagyk382eCjiJtXWRWaFxmB57jHwEVEnCXWjIFF BA3iNhKC4lsV0NC3Qxo4sxhNjmp5fGfKl6gCiXWoI6GKFUPVRWdCSoBhVMomYk0kht69 fmi/LuJEifjQc3UMY8N6QKHXgquQLIrWviRJwh9FJQblpOZ4OI8Pg9K4X7gJOEHROTHw i99g==
X-Gm-Message-State: AOJu0YziQJGxQi0HT7Qy+MAXGTAMEY32xXCAsizE888KVvdpm52vNvow PnHuieRImu8SAH4N3zdI2LQw7xa4hoDK+PfmrhCIAayCqvdeoSgzoa02CwY9VgpwEjqzw1gm7eu BbXxc1azALyVloZudoJmi9h8F+D8JCicOHVpXUQ==
X-Google-Smtp-Source: AGHT+IHxNjVw6C/DssCBpdyy0P4Suc0VcdhHwLo7/zUCg+YIs7oSTRDK+3CelE6GHi5k2225gesHpnv905deQ96ek6w=
X-Received: by 2002:a0d:eac7:0:b0:608:5245:3936 with SMTP id t190-20020a0deac7000000b0060852453936mr1875681ywe.2.1708410949376; Mon, 19 Feb 2024 22:35:49 -0800 (PST)
MIME-Version: 1.0
From: Sachin Mamoru <sachinmamoru@gmail.com>
Date: Tue, 20 Feb 2024 12:05:38 +0530
Message-ID: <CAD=XBCrMkpjuqwYOjZ4TfBqQu2ik6HNSA4zCizZB+rCMyJHpWA@mail.gmail.com>
To: oauth@ietf.org
Cc: thilinasenarath97@gmail.com, janak@wso2.com, Sachin Mamoru <sachinm@wso2.com>, anshajanth@wso2.com
Content-Type: multipart/alternative; boundary="000000000000c49e280611ca6b3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Z7JnXHDvQ_ZOPsbk0FpICP5-XjQ>
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 <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: Tue, 20 Feb 2024 06:37:01 -0000

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  <https://sachinmamoru.me>
sachinmamoru@gmail.com  <sachinmamoru@gmail.com>
<https://www.linkedin.com/in/sachin-mamoru/>
<https://twitter.com/MamoruSachin>