Re: [OAUTH-WG] OAuth 2.0 Discovery Location

"Manger, James" <> Thu, 25 February 2016 07:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8965E1A8A99 for <>; Wed, 24 Feb 2016 23:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9uCIXtb0-Rzd for <>; Wed, 24 Feb 2016 23:07:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D4161A8978 for <>; Wed, 24 Feb 2016 23:07:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,497,1449493200"; d="scan'208,217";a="150378054"
Received: from unknown (HELO ([]) by with ESMTP; 25 Feb 2016 18:05:59 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8085"; a="83330451"
Received: from ([]) by with ESMTP; 25 Feb 2016 18:03:14 +1100
Received: from ([]) by ([fe80::91f4:aabc:bfb0:95c4%16]) with mapi; Thu, 25 Feb 2016 18:02:36 +1100
From: "Manger, James" <>
To: George Fletcher <>, "<>" <>
Date: Thu, 25 Feb 2016 18:02:35 +1100
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AdFvN/cbviXvE7HsQxyyCWEJ5zKKMAAXzyEw
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBB0194A6WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Feb 2016 07:07:10 -0000

> I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture

The AS is issuing temporary credentials (access_tokens) to clients but doesn’t know where those credentials will work? That’s broken.

An AS should absolutely indicate where an access_token can be used. draft-sakimura-oauth-meta suggests indicating this with 1 or more “ruri” (resource URI) values in an HTTP Link header. A better approach would be including a list of web origins in the token response beside the access_token field.

James Manger

From: OAuth [] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt <>; Nat Sakimura <>
Cc: <> <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I'm concerned that forcing the AS to know about all RS's endpoints that will accept it's tokens creates a very brittle deployment architecture. What if a RS moves to a new endpoint? All clients would be required to get new tokens (if I understand correctly). And the RS move would have to coordinate with the AS to make sure all the timing is perfect in the switch over of endpoints.

I suspect a common deployment architecture today is that each RS requires one or more scopes to access it's resources. The client then asks the user to authorize a token with a requested list of scopes. The client can then send the token to the appropriate RS endpoint. The RS will not authorize access unless the token has the required scopes.

If the concern is that the client may accidentally send the token to a "bad" RS which will then replay the token, then I'd rather use a PoP mechanism because the point is that you want to ensure the correct client is presenting the token. Trying to ensure the client doesn't send the token to the wrong endpoint seems fraught with problems.