jspωiki
OAuth 2.0 Incremental Authorization

Overview[1]#

OAuth 2.0 Incremental Authorization is an Incremental authorization Implementation and part of the concept of Principle of least privilege where as an entity is only granted privileges required.

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.

OAuth 2.0 Incremental Authorization may require additional level of Authentication or Authorization to be granted access to the resource.

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.

OAuth 2.0 Incremental Authorization and Google[2]#

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 combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one OAuth Scopes using an application's desktop client and then granted another OAuth Scopes to the same application via a mobile Device, the combined authorization would include both scopes.

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.

More Information#

There might be more information for this subject on one of the following: