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

Version management

Difference between version and

At line 1 added 30 lines
!!! Overview
[{$pagename}] ([AS]) is an [Actor] within [OAuth 2.0] and [OpenID Connect] which typically provides the [Security Token Service] (STS) or colloquially, the server that issues [tokens].
[{$pagename}] is the [Application] for issuing the [OAuth Client] [tokens] which allows [access] to the data on the [Resource Server] on behalf of [Resource Owner].
Typically the [{$pagename}] could also be an [Identity Provider (IDP)] though there is no reason that they could not be separate servers.
!! [Policy Administration Point]
Typically we can think of the [{$pagename}] as the [Policy Information Point] where the the policy is defined and subsequently stored. The [Resource Server] is the [Policy Enforcement Point] where the policiy is enforced.
!! Components
[{$pagename}] typically has the following components:
* An [Authorization_endpoint] component - typically a login page presented to the [Resource Owner] backed by an [Identity Provider (IDP)]
** where [Consent] [component|Consent Mechanism] - For obtaining consent from the [Resource Owner] for [Delegation] of the [Protected Resource] to the [OAuth Client]
* A [Security Token Service] ([Token_endpoint]) component for managing [Tokens]
* [Openid-configuration] [Endpoint] introduced by [OpenID Connect]
The [{$pagename}] and the [Resource Server] could be the same server, but it doesn't have to. The [OAuth 2.0] [specification] does not provide an [Authentication] protocol for the [Resource Owner]. It strongly suggests that [OAuth Client] applications should use [Authorization Header] for accessing the [Token_endpoint], but it says nothing about the [Authentication] of [Resource Owner] when their approval is needed for a [Delegation] (only that they must be [Authenticated|Authentication]). This allows [Authentication] completely orthogonal to the approval process, and [{$pagename}] are free to implement the [Authentication] any way they choose.
The [User Managed Access|User-Managed Access] standardizes their communication and this is really critical because as use cases for potentially putting them in different domains run by different companies.
[{$pagename}] has a [Authorization Server Operator] that is in [User-Managed Access] ([UMA]) [Legal Person] that operates the [{$pagename}].
!! Typical Implementation
In a typical Implementation the [{$pagename}] acts both as the [Policy Decision Point] and also as the [Policy Enforcement Point] that protects the [OAuth 2.0] [Authorization Endpoint|Authorization_endpoint].
!! 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