OAuth 2.0 authorization requests that include every scope the client might ever need can result in over-scoped authorization and a sub-optimal Resource Owner consent User Experience. This specification enhances the OAuth 2.0 authorization protocol by adding Incremental authorization, the ability to request specific authorization OAuth Scopes as needed, when they're needed, removing the requirement to request every possible OAuth Scopes that might be needed upfront.
When the same entity accesses a new resource which requires additional privileges, they are then evaluated and if desired "added" without the entity without the entity starting over in the Authorization process.
There is an Internet Draft for OAuth 2.0 Incremental Authorization available at OAuth 2.0 Incremental Authorization and defines a new parameter include_granted_scopes to to be part of the Authorization Request.Google refers to OAuth 2.0 Incremental Authorization in reference to OAuth 2.0 as you complete the normal flow for requesting an access_token but make sure that the Authorization Request includes previously granted scopes. This approach allows your application to avoid having to manage multiple access_tokens.
The following rules apply to an access_tokens obtained from an OAuth 2.0 Incremental Authorization:
- The access_token can be used to access resources corresponding to any of the OAuth Scopes rolled into the new, combined authorization.
- When you use the refresh_token for the combined authorization to obtain an access_token, the access_token represents the combined authorization and can be used for any of its OAuth Scopes.
- If you revoke a token that represents a combined authorization, access to all of that authorization's OAuth Scopes on behalf of the associated user are revoked simultaneously.
We assume that the OAuth 2.0 Incremental Authorization could also work if the OAuth 2.0 Incremental Authorization also required a Higher level of Authorization as might be encountered with a Authorization Request that included a new amr_values.
OAuth 2.0 Incremental Authorization and Authorization Servers OAuth Confidential Clients, such as web servers that can keep secrets, the Authorization_endpoint SHOULD treat OAuth Scopes that the user already granted differently on the consent user interface.
To avoid the need for OAuth Confidential Clients to re-request already authorized OAuth Scopes, authorization servers MAY support an additional "include_granted_scopes" parameter in the Authorization Request. This parameter, enables the client to request tokens during the authorization grant exchange that represent the full scope of the user's grant to the application including any previous grants, without the app needing to track the scopes directly.
OAuth Public Clients are NOT RECOMMENDED to automatically approve OAuth requests for OAuth Public Clients without user consent (see Section 10.2 of OAuth 2.0 RFC 6749, and Section 8.6 of OAuth 2.0 RFC 8252), thus Authorization Grants shouldn't contain previously authorized scopes in the manner described above for confidential clients.
OAuth Public Clients (and OAuth Confidential Clients using this technique) should instead track the scopes for every Authorization Grant, and only request yet to be granted OAuth Scopes during OAuth 2.0 Incremental Authorization.