From 05b1a508517a45f199bbaf5b07c3244491d31134 Mon Sep 17 00:00:00 2001 From: David Shanske Date: Sun, 17 Oct 2021 03:15:35 +0000 Subject: [PATCH] Update to note scope or resource may be requested --- public/source/index.php | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/public/source/index.php b/public/source/index.php index b539e76..d04ae07 100644 --- a/public/source/index.php +++ b/public/source/index.php @@ -355,7 +355,7 @@ +

If a request omits both a scope and a resource, the authorization server MUST NOT issue an access token for this authorization code. Only the user's profile URL may be returned without any scope or resource requested. See Profile Information for details about which scopes to request to return user profile information.

+ 
The authorization endpoint MAY use the provided me query component as a hint of which user is attempting to sign in, and to indicate which profile URL the client is expecting in the resulting profile URL response or access token response. This is specifically helpful for authorization endpoints where users have multiple supported profile URLs, so the authorization endpoint can make an informed decision as to which profile URL the user meant to identify as. Note that from the authorization endpoint's view, this value as provided by the client is unverified external data and MUST NOT be assumed to be valid data at this stage. If the logged-in user doesn't match the provided me parameter by the client, the authorization endpoint MAY either ignore the me parameter completely or display an error, at the authorization endpoint's discretion.

 
-          
Once the user is authenticated, the authorization endpoint presents the authorization request to the user. The prompt MUST indicate which application the user is signing in to, and SHOULD provide as much detail as possible about the request, such as information about the requested scopes.

+          
Once the user is authenticated, the authorization endpoint presents the authorization request to the user. The prompt MUST indicate which application the user is signing in to, and SHOULD provide as much detail as possible about the request, such as information about the requested scopes or resources.

 
         

           
Authorization Response

@@ -527,9 +529,9 @@
         

           
Access Token Response

 
-          
When the client receives an authorization code that was requested with one or more scopes that will result in an access token being returned, the client will exchange the authorization code at the token endpoint.

+          
When the client receives an authorization code that was requested with one or more scopes/resources that will result in an access token being returned, the client will exchange the authorization code at the token endpoint.

 
-          
The token endpoint needs to verify that the authorization code is valid, and that it was issued for the matching client_id and redirect_uri, contains at least one scope, and checks that the provided code_verifier hashes to the same value as given in the code_challenge in the original authorization request. If the authorization code was issued with no scope, the token endpoint MUST NOT issue an access token, as empty scopes are invalid per Section 3.3 of OAuth 2.0 [[!RFC6749]].

+          
The token endpoint needs to verify that the authorization code is valid, and that it was issued for the matching client_id and redirect_uri, contains at least one scope or resource, and checks that the provided code_verifier hashes to the same value as given in the code_challenge in the original authorization request. If the authorization code was issued with no scope or resource, the token endpoint MUST NOT issue an access token, as empty scopes are invalid per Section 3.3 of OAuth 2.0 [[!RFC6749]].

 
           
The specifics of how the token endpoint verifies the authorization code are out of scope of this document, as typically the authorization endpoint and token endpoint are part of the same system and can share storage or another private communication mechanism.

 
@@ -763,8 +765,8 @@
 
      
In requests to the authorization server, a client MAY indicate the protected resource (a.k.a. resource server, application, API, etc.) to which it is requesting access by including a "resource" parameter in the request, as described in [[RFC8707]] Resource Indicators for OAuth 2.0.
 
 
-     
The parameter value identifies a resource to which the client is requesting access. The client SHOULD provide the most specific URI that it can for the complete API or set of resources it intends to access. It differs from [[RRFC8707]] in that the parameter value MUST correspond to a network addressable location of the protect resource.  The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter.

-     
If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a predefined default resource value.

+     
The parameter value identifies a resource to which the client is requesting access. The client SHOULD provide the most specific URI that it can for the complete API or set of resources it intends to access. It differs from [[RFC8707]] in that the parameter value MUST correspond to a network addressable location of the protect resource.  The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter.

+     
If the client omits the "resource" parameter when requesting authorization, the authorization server MAY process the request with no specific resource or by using a predefined default resource value. If a client provides a "resource" parameter, they may omit the "scope" parameter. A token MUST not be issued if both the scope and the resource parameters are omitted.

 
      
When the "resource" parameter is used on an access token request made to the token endpoint, for all grant types, it indicates the target service or protected resource where the client intends to use the requested access token.