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
Authorization API
Authorization API

Version management

Difference between version and

At line 1 added 14 lines
!!! Overview
[User-Managed Access] defines the [Authorization Server] __MUST__ present an HTTP-based [Authorization] [API], protected by [TLS] and [OAuth 2.0] (or an OAuth-based authentication protocol), for use by [OAuth Clients]. The [Authorization Server] thus has an OAuth [Token_endpoint] and [Authorization_endpoint]. The [Authorization Server] __MUST__ declare its [Authorization API Endpoint] in its [Uma-configuration] data.
The [{$pagename}] consists of one [Endpoint], the [Requesting Party Token Endpoint]
An [Entity] seeking [{$pagename}] access __MUST__ have the [OAuth Scope] "[uma_authorization]". An [Access Token] with at least this [OAuth Scope] is called an [Authorization API Token] ([AAT]) and an entity that can acquire an [Authorization API Token] is by definition a [OAuth Client]. A single entity can serve in both [Resource Server] and [OAuth Client] roles if it has [Access Tokens] with the appropriate [OAuth Scopes]. If a request to an [Endpoint] fails due to an invalid, missing, or expired [Authorization API Token], or requires [higher privileges|Level Of Assurance] at this endpoint than provided by the [Authorization API Token], the [Authorization Server] responds with an [OAuth Error].
The [Authorization Server] __MUST__ support the [OAuth Bearer Token Profile|OAuth-bearer] for [Authorization API Token] issuance, and MAY support other [OAuth Token Profiles]. The [Authorization Server] __MUST__ declare all supported [OAuth Token Profiles] and [Grant Types] for [Authorization API Token] issuance in its [uma-configuration] data. Any OAuth authorization grant type might be appropriate depending on circumstances; for example, the [Client Credentials Grant] is useful in the case of an organization acting as a [Requesting Party]. [UMA ImplementerS Guide|UMA Implementer Guide] discusses grant options further.
An [Authorization API Token] binds a [Requesting Party], a [OAuth Client] being used by that party, and an [Authorization Server] that protects resources this [OAuth Client] is seeking access to on this [Requesting Party]'s behalf. It is not specific to any [Resource Server] or [Resource Owner]. The issuance of an AAT represents the approval of this [Requesting Party] for this [OAuth Client] to engage with this [Authorization Server] to supply claims, ask for [Authorization], and perform any other tasks needed for obtaining authorization for access to [Protected Resources] at all [Resource Servers] that use this [Authorization Server]. The [Authorization Server] is able to manage future processes of authorization and claims-caching efficiently for this [OAuth Client]/[Requesting Party] pair across all [Resource Servers] they try to access; however, these management processes are __outside__ the scope of this specification.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop