2.1. Authorization Request

When the resource parameter is used in an authorization request to the authorization endpoint, it indicates the identity of the protected resource(s) to which access is being requested. When an access token will be returned directly from the authorization endpoint via the implicit flow (Section 4.2 of OAuth 2.0 [RFC6749]), the requested resource is applicable to that access token. In the code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate representation of the authorization grant (the authorization code) is returned from the authorization endpoint, the requested resource is applicable to the full authorization grant.

For an authorization request sent as a JSON Web Token (JWT), such as when using the JWT Secured Authorization Request [JWT-SAR], a single resource parameter value is represented as a JSON string while multiple values are represented as an array of strings.

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. Alternatively, the authorization server MAY require clients to specify the resource(s) they intend to access and MAY fail requests that omit the parameter with an invalid_target error. The authorization server might use this data to inform the user about the resources the client is going to access on their behalf, to apply policy (e.g., refuse the request due to unknown resources), and to determine the set of resources that can be used in subsequent access token requests.

If the authorization server fails to parse the provided value(s) or does not consider the resource(s) acceptable, it should reject the request with an error response using the error code invalid_target as the value of the error parameter and can provide additional information regarding the reasons for the error using the error_description.

An example of an authorization request where the client tells the authorization server that it wants an access token for use at https://api.example.com/app/ is shown in Figure 1 below (extra line breaks and indentation are for display purposes only).

GET /as/authorization.oauth2?response_type=token
   &client_id=example-client
   &state=XzZaJlcwYew1u0QBrRv_Gw
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com

Figure 1: Implicit Flow Authorization Request

Below in Figure 2 is an example of an authorization request using the code response type where the client is requesting access to the resource owner's contacts and calendar data at https://cal.example.com/ and https://contacts.example.com/ (extra line breaks and indentation are for display purposes only).

GET /as/authorization.oauth2?response_type=code
   &client_id=s6BhdRkqt3
   &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &scope=calendar%20contacts
   &resource=https%3A%2F%2Fcal.example.com%2F
   &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com

Figure 2: Code Flow Authorization Request

2.1. Authorization Request​

2.1. Authorization Request