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
Federated Authorization for UMA 2.0
Federated Authorization for UMA 2.0

Version management

Difference between version and

At line 1 added 18 lines
!!! Overview
[{$pagename}] ([UMAFedAuthz]) defines a means for an [UMA]-enabled [Authorization Server] and [Resource Server] to be loosely coupled, or [federated|Federation], in a [Resource Owner] [context].
[{$pagename}] is designed for use with [HTTP] [RFC 2616], and for interoperability and security in the [context] of loosely coupled services and [applications] operated by independent parties in independent [domains]. The use of [UMA] over any [protocol] other than [HTTP] is undefined. In such circumstances, it is [RECOMMENDED] to define profiles or extensions to achieve interoperability among independent implementations (see Section 4 of [UMAGrant]).
The [Authorization Server] [MUST] use [TLS] protection over its [Protection API] endpoints, as governed by [BCP 195], which discusses deployment and adoption characteristics of different [TLS] versions.
The [Authorization Server] [MUST] use [OAuth] and require a [Protection API Token] to secure its [Protection API] endpoints.
As defined in [UMAGrant], the [Resource Owner] -- the [entity] here authorizing [Protection API Token] issuance -- [MAY] be an [End-User] (natural person) or a non-human entity treated as a person for limited [legal] purposes ([Legal Person]), such as a corporation. A [Protection API Token] is unique to a [Resource Owner], [Resource Server] used for resource management, and [Authorization Server] used for protection of those [resources]. The issuance of the [Protection API Token] represents the [authorization] of the [Resource Owner] for the [Resource Server] to use the [Authorization Server] for protecting those resources.
Different [Grant Types] for [Protection API Token] issuance might be appropriate for different types of [Resource Owners]; for [example], the [Client Credentials Grant] is useful in the case of an organization acting as a [Resource Owner], whereas an interactive grant type is typically more appropriate for capturing the approval of an [End-User] [Resource Owner]. Where an [Identity Token] is desired in addition to an [Access Token], it is [RECOMMENDED] to use [OpenID.Core] in addition.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Federated Authorization for User-Managed Access (UMA) 2.0|https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html|target='_blank'] - based on information obtained 2017-07-10-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop