This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
OAuth 2.0 Incremental Authorization
OAuth 2.0 Incremental Authorization

Version management

Difference between version and

At line 1 added 60 lines
!!! Overview[1]
[{$pagename}] 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.
[{$pagename}] may require additional level of [Authentication] or [Authorization] to be granted [access] to the resource.
There is an [Internet Draft] for [{$pagename}] available at [OAuth 2.0 Incremental Authorization|https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth-01|target='_blank'] and defines a new parameter include_granted_scopes to to be part of the [Authorization Request].
!! [{$pagename}] and [Google][2]
[Google] refers to [{$pagename}] 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|OAuth 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 [{$pagename}]:
* 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].
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.
* 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 [{$pagename}] could also work if the [{$pagename}] also required a Higher level of [Authorization] as might be encountered with a [Authorization Request] that included a new [amr_values].
[{$pagename}] 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 [{$pagename}].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [OAuth 2.0 Incremental Authorization|https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02|target='_blank'] - based on information obtained 2018-04-09
* [#2] - [Incremental authorization|https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth|target='_blank'] - based on information obtained 2018-04-09
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop