Network Working Group E. Maler, Ed.
Internet-Draft ForgeRock
Intended status: Informational M. Machulak
Expires: August 17, 2019 HSBC
J. Richer
Bespoke Engineering
T. Hardjono
MIT
February 13, 2019
Federated Authorization for User-Managed Access (UMA) 2.0
draft-maler-oauth-umafedauthz-00
Abstract
This specification defines a means for an UMA-enabled authorization
server and resource server to be loosely coupled, or federated, in a
secure and authorized resource owner context.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Maler, et al. Expires August 17, 2019 [Page 1]
Internet-Draft February 2019
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Abstract Flow . . . . . . . . . . . . . . . . . . . . . . 4
1.3. HTTP Usage, API Security, and Identity Context . . . . . 5
1.4. Separation of Responsibility and Authority . . . . . . . 6
1.5. Protection API Summary . . . . . . . . . . . . . . . . . 7
1.5.1. Permissions . . . . . . . . . . . . . . . . . . . . . 8
2. Authorization Server Metadata . . . . . . . . . . . . . . . . 8
3. Resource Registration Endpoint . . . . . . . . . . . . . . . 9
3.1. Resource Description . . . . . . . . . . . . . . . . . . 11
3.1.1. Scope Description . . . . . . . . . . . . . . . . . . 12
3.2. Resource Registration API . . . . . . . . . . . . . . . . 13
3.2.1. Create Resource Description . . . . . . . . . . . . . 14
3.2.2. Read Resource Description . . . . . . . . . . . . . . 15
3.2.3. Update Resource Description . . . . . . . . . . . . . 16
3.2.4. Delete Resource Description . . . . . . . . . . . . . 17
3.2.5. List Resource Descriptions . . . . . . . . . . . . . 17
4. Permission Endpoint . . . . . . . . . . . . . . . . . . . . . 18
4.1. Resource Server Request to Permission Endpoint . . . . . 20
4.2. Authorization Server Response to Resource Server on
Permission Request Success . . . . . . . . . . . . . . . 22
4.3. Authorization Server Response to Resource Server on
Permission Request Failure . . . . . . . . . . . . . . . 23
5. Token Introspection Endpoint . . . . . . . . . . . . . . . . 23
5.1. Resource Server Request to Token Introspection Endpoint . 24
5.1.1. Authorization Server Response to Resource Server on
Token Introspection Success . . . . . . . . . . . . . 25
6. Error Messages . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. OAuth 2.0 Authorization Server Metadata Registry . . . . 28
9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 28
9.2. OAuth Token Introspection Response Registration . . . . . 28
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 28
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Maler, et al. Expires August 17, 2019 [Page 2]
Internet-Draft February 2019
1. Introduction
This specification extends and complements [UMAGrant] to loosely
couple, or federate, its authorization process. This enables
multiple resource servers operating in different domains to
communicate with a single authorization server operating in yet
another domain that acts on behalf of a resource owner. A service
ecosystem can thus automate resource protection, and the resource
owner can monitor and control authorization grant rules through the
authorization server over time. Further, authorization grants can
increase and decrease at the level of individual resources and
scopes.
Building on the example provided in the introduction in [UMAGrant],
bank customer (resource owner) Alice has a bank account service
(resource server), a cloud file system (different resource server
hosted elsewhere), and a dedicated sharing management service
(authorization server) hosted by the bank. She can manage access to
her various protected resources by spouse Bob, accounting
professional Charline, financial information aggregation company
DecideAccount, and neighbor Erik (requesting parties), all using
different client applications. Her bank accounts and her various
files and folders are protected resources, and she can use the same
sharing management service to monitor and control different scopes of
access to them by these different parties, such as viewing, editing,
or printing files and viewing account data or accessing payment
functions.
This specification, together with [UMAGrant], constitutes UMA 2.0.
This specification is OPTIONAL to use with the UMA grant.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Unless otherwise noted, all parameter names and values are case
sensitive. JSON [RFC7159] data structures defined in this
specification MAY contain extension parameters that are not defined
in this specification. Any entity receiving or retrieving a JSON
data structure SHOULD ignore extension parameters it is unable to
understand. Extension names that are unprotected from collisions are
outside the scope of this specification.
Maler, et al. Expires August 17, 2019 [Page 3]
Internet-Draft February 2019
1.2. Abstract Flow
The UMA grant defined in [UMAGrant] enhances the abstract protocol
flow of OAuth. This specification enhances the UMA grant by defining
formal communications between the UMA-enabled authorization server
and resource server as they act on behalf of the resource owner,
responding to authorization and resource requests, respectively, by a
client that is acting on behalf of a requesting party.
A summary of UMA 2.0 communications, combining the UMA grant with
federated authorization, is shown in Figure 1.
+------------------+
| resource |
+------------manage (out of scope)----| owner |
| +------------------+
| |
| protection |
| API access control
| token (PAT) (out of scope)
| |
v v
+------------+ +----------+------------------+
| | |protection| |
| resource | | API | authorization |
| server |<-----protect-------| (needs | server |
| | | PAT) | |
+------------+ +----------+------------------+
| protected | | UMA |
| resource | | grant |
|(needs RPT) | requesting | (PCT optional) |
+------------+ party token +------------------+
^ (RPT) ^ persisted ^
| | claims |
| push token |
| claim (PCT) |
| tokens interact
| +--------+ for
+------------access--------------------| client | claims
+--------+ gathering
+---------------+
| requesting |
| party |
+---------------+
Figure 1: Federated Authorization Enhancements to UMA Grant Flow
Maler, et al. Expires August 17, 2019 [Page 4]
Internet-Draft February 2019
This specification uses all of the terms and concepts in [UMAGrant].
This figure introduces the following new concepts:
protection API The API presented by the authorization server to the
resource server, defined in this specification. This API is
OAuth-protected.
protection API access token (PAT) An [RFC6749] access token with the
scope "uma_protection", used by the resource server as a client
of the authorization server's protection API. The resource
owner involved in the UMA grant is the same entity taking on
the role of the resource owner authorizing issuance of the PAT.
1.3. HTTP Usage, API Security, and Identity Context
This specification is designed for use with HTTP [RFC2616], 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 [BCP195], which discusses deployment
and adoption characteristics of different TLS versions.
The authorization server MUST use OAuth and require a valid PAT to
secure its protection API endpoints. The authorization server and
the resource server (as an OAuth client) MUST support bearer usage of
the PAT, as defined in [RFC6750]. All examples in this specification
show the use of bearer-style PATs in this format.
As defined in [UMAGrant], the resource owner -- the entity here
authorizing PAT 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 PAT 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 PAT represents the authorization of the resource
owner for the resource server to use the authorization server for
protecting those resources.
Different grant types for PAT 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.
Maler, et al. Expires August 17, 2019 [Page 5]
Internet-Draft February 2019
Where an identity token is desired in addition to an access token, it
is RECOMMENDED to use [OIDCCore] in addition.
1.4. Separation of Responsibility and Authority
Federation of authorization for the UMA grant delivers a conceptual
separation of responsibility and authority:
o The resource owner can control access to resources residing at
multiple resource servers from a single authorization server, by
virtue of authorizing PAT issuance for each resource server. Any
one resource server MAY be operated by a party different from the
one operating the authorization server.
o The resource server defines the boundaries of resources and the
scopes available to each resource, and interprets how clients'
resource requests map to permission requests, by virtue of being
the publisher of the API being protected and using the protection
API to communicate to the authorization server.
o The resource owner works with the authorization server to
configure policy conditions (authorization grant rules), which the
authorization server executes in the process of issuing access
tokens. The authorization process makes use of claims gathered
from the requesting party and client in order to satisfy all
operative operative policy conditions.
The separation of authorization decision making and authorization
enforcement is similar to the architectural separation often used in
enterprises between policy decision points and policy enforcement
points. However, the resource server MAY apply additional
authorization controls beyond those imposed by the authorization
server. For example, even if an RPT provides sufficient permissions
for a particular case, the resource server can choose to bar access
based on its own criteria.
Practical control of access among loosely coupled parties typically
requires more than just messaging protocols. It is outside the scope
of this specification to define more than the technical contract
between UMA-conforming entities. Laws may govern authorization-
granting relationships. It is RECOMMENDED for the resource owner,
authorization server, and resource server to establish agreements
about which parties are responsible for establishing and maintaining
authorization grant rules and other authorization rules on a legal or
contractual level, and parties operating entities claiming to be UMA-
conforming should provide documentation of rights and obligations
between and among them. See Section 4 of [UMAGrant] for more
information.
Maler, et al. Expires August 17, 2019 [Page 6]
Internet-Draft February 2019
Except for PAT issuance, the resource owner-resource server and
resource owner-authorization server interfaces -- including the
setting of policy conditions -- are outside the scope of this
specification (see Section 8 and Section 6.1 of [UMAGrant] for
privacy considerations). Some elements of the protection API enable
the building of user interfaces for policy condition setting (for
example, see Section 3.2, which can be used in concert with user
interaction for resource protection and sharing and offers an end-
user redirection mechanism for policy interactions).
Note: The resource server typically requires access to at least the
permission and token introspection endpoints when an end-user
resource owner is not available ("offline" access). Thus, the
authorization server needs to manage the PAT in a way that ensures
this outcome. [UMA-Impl] discusses ways the resource server can
enhance its error handling when the PAT is invalid.
1.5. Protection API Summary
The protection API defines the following endpoints:
o Resource registration endpoint as defined in Section 3. The API
available at this endpoint provides a means for the resource
server to put resources under the protection of an authorization
server on behalf of the resource owner and manage them over time.
o Permission endpoint as defined in Section 4. This endpoint
provides a means for the resource server to request a set of one
or more permissions on behalf of the client based on the client's
resource request when that request is unaccompanied by an access
token or is accompanied by an RPT that is insufficient for access
to that resource.
o OPTIONAL token introspection endpoint as defined in [RFC7662] and
as extended in Section 5. This endpoint provides a means for the
resource server to introspect the RPT.
Use of these endpoints assumes that the resource server has acquired
OAuth client credentials from the authorization server by static or
dynamic means, and has a valid PAT. Note: Although the resource
identifiers that appear in permission and token introspection request
messages could sufficiently identify the resource owner, the PAT is
still required because it represents the resource owner's
authorization to use the protection API, as noted in Section 1.3.
The authorization server MUST declare its protection API endpoints in
the discovery document (see Section 2).
Maler, et al. Expires August 17, 2019 [Page 7]
Internet-Draft February 2019
1.5.1. Permissions
A permission is (requested or granted) authorized access to a
particular resource with some number of scopes bound to that
resource. The concept of permissions is used in authorization
assessment, results calculation, and RPT issuance in [UMAGrant].
This concept takes on greater significance in relation to the
protection API.
The resource server's resource registration operations at the
authorization server result in a set of resource owner-specific
resource identifiers. When the client makes a resource request that
is unaccompanied by an access token or its resource request fails,
the resource server is responsible for interpreting that request and
mapping it to a choice of authorization server, resource owner,
resource identifier(s), and set of scopes for each identifier, in
order to request one or more permissions -- resource identifiers and
a set of scopes -- and obtain a permission ticket on the client's
behalf. Finally, when the client has made a resource request
accompanied by an RPT and token introspection is in use, the returned
token introspection object reveals the structure of permissions,
potentially including expiration of individual permissions.
2. Authorization Server Metadata
This specification makes use of the authorization server discovery
document structure and endpoint defined in [UMAGrant]. The resource
server uses this discovery document to discover the endpoints it
needs.
In addition to the metadata defined in that specification and
[OAuthMeta], this specification defines the following metadata for
inclusion in the discovery document:
permission_endpoint
REQUIRED. The endpoint URI at which the resource server requests
permissions on the client's behalf.
resource_registration_endpoint
REQUIRED. The endpoint URI at which the resource server registers
resources to put them under authorization manager protection.
Following are additional requirements related to metadata:
introspection_endpoint
If the authorization server supports token introspection as
defined in this specification, it MUST supply this metadata value
(defined in [OAuthMeta]).
Maler, et al. Expires August 17, 2019 [Page 8]
Internet-Draft February 2019
The authorization server SHOULD document any profiled or extended
features it supports explicitly, ideally by supplying the URI
identifying each UMA profile and extension as an
"uma_profiles_supported" metadata array value (defined in
[UMAGrant]), and by using extension metadata to indicate specific
usage details as necessary.
3. Resource Registration Endpoint
The API available at the resource registration endpoint enables the
resource server to put resources under the protection of an
authorization server on behalf of the resource owner and manage them
over time. Protection of a resource at the authorization server
begins on successful registration and ends on successful
deregistration.
The resource server uses a RESTful API at the authorization server's
resource registration endpoint to create, read, update, and delete
resource descriptions, along with retrieving lists of such
descriptions. The descriptions consist of JSON documents that are
maintained as web resources at the authorization server. (Note
carefully the similar but distinct senses in which the word
"resource" is used in this section.)
Figure 2 illustrates the resource registration API operations, with
requests and success responses shown.
Maler, et al. Expires August 17, 2019 [Page 9]
Internet-Draft February 2019
authorization resource resource
server server owner
| | |
|*PROTECTION API: | |
|*Resource registration | |
|endpoint/API | |
| | |
|*Create resource (POST)| |
|<----------------------| |
|*201 Created with | |
|resource ID | |
|---------------------->| |
| | |
|Set policy conditions (anytime |
|before deletion/deregistration) |
|<- - - - - - - - - - - - - - - - - - - -|
| | |
|*Read (GET) with | |
|resource ID | |
|<----------------------| |
|*200 OK with resource | |
|representation | |
|---------------------->| |
|*Update (PUT) with | |
|resource ID | |
|<----------------------| |
|*200 OK with resource | |
|ID | |
|---------------------->| |
|*List (GET) | |
|<----------------------| |
|*200 OK with list of | |
|resource IDs | |
|---------------------->| |
|*Delete (DELETE) with | |
|resource ID | |
|<----------------------| |
|*200 OK or 204 No | |
|Content | |
|---------------------->| |
Figure 2: Resource Registration Endpoint and API: Requests and
Success Responses
The resource server MAY protect any subset of the resource owner's
resources using different authorization servers or other means
entirely, or to protect some resources and not others. Additionally,
the choice of protection regimes MAY be made explicitly by the
Maler, et al. Expires August 17, 2019 [Page 10]
Internet-Draft February 2019
resource owner or implicitly by the resource server. Any such
partitioning by the resource server or owner is outside the scope of
this specification.
The resource server MAY register a single resource for protection
that, from its perspective, has multiple parts, or has dynamic
elements such as the capacity for querying or filtering, or otherwise
has internal complexity. The resource server alone is responsible
for maintaining any required mappings between internal
representations and the resource identifiers and scopes known to the
authorization server.
Note: The resource server is responsible for managing the process and
timing of registering resources, maintaining the registration of
resources, and deregistering resources at the authorization server.
Motivations for updating a resource might include, for example, new
scopes added to a new API version or resource owner actions at a
resource server that result in new resource description text. See
[UMA-Impl] for a discussion of initial resource registration timing
options.
3.1. Resource Description
A resource description is a JSON document that describes the
characteristics of a resource sufficiently for an authorization
server to protect it. A resource description has the following
parameters:
resource_scopes REQUIRED. An array of strings, serving as scope
identifiers, indicating the available scopes for this resource.
Any of the strings MAY be either a plain string or a URI.
description OPTIONAL. A human-readable string describing the
resource at length. The authorization server MAY use this
description in any user interface it presents to a resource owner,
for example, for resource protection monitoring or policy setting.
The value of this parameter MAY be internationalized, as described
in Section 2.2 of [RFC7591].
icon_uri OPTIONAL. A URI for a graphic icon representing the
resource. The authorization server MAY use the referenced icon in
any user interface it presents to a resource owner, for example,
for resource protection monitoring or policy setting.
name OPTIONAL. A human-readable string naming the resource. The
authorization server MAY use this name in any user interface it
presents to a resource owner, for example, for resource protection
Maler, et al. Expires August 17, 2019 [Page 11]
Internet-Draft February 2019
monitoring or policy setting. The value of this parameter MAY be
internationalized, as described in Section 2.2 of [RFC7591].
type OPTIONAL. A string identifying the semantics of the resource.
For example, if the resource is an identity claim that leverages
standardized claim semantics for "verified email address", the
value of this parameter could be an identifying URI for this
claim. The authorization server MAY use this information in
processing information about the resource or displaying
information about it in any user interface it presents to a
resource owner.
For example, this description characterizes a resource (a photo
album) that can potentially be viewed or printed; the scope URI
points to a scope description as defined in Section 3.1.1:
{
"resource_scopes":[
"view",
"http://photoz.example.com/dev/scopes/print"
],
"description":"Collection of digital photographs",
"icon_uri":"http://www.example.com/icons/flower.png",
"name":"Photo Album",
"type":"http://www.example.com/rsrcs/photoalbum"
}
3.1.1. Scope Description
A scope description is a JSON document that describes the
characteristics of a scope sufficiently for an authorization server
to protect the resource with this available scope.
While a scope URI appearing in a resource description (see
Section 3.1) MAY resolve to a scope description document, and thus
scope description documents are possible to standardize and reference
publicly, the authorization server is not expected to resolve scope
description details at resource registration time or at any other
run-time requirement. The resource server and authorization server
are presumed to have negotiated any required interpretation of scope
handling out of band.
A scope description has the following parameters:
description OPTIONAL. A human-readable string describing the
resource at length. The authorization server MAY use this
description in any user interface it presents to a resource owner,
for example, for resource protection monitoring or policy setting.
Maler, et al. Expires August 17, 2019 [Page 12]
Internet-Draft February 2019
The value of this parameter MAY be internationalized, as described
in Section 2.2 of [RFC7591].
icon_uri OPTIONAL. A URI for a graphic icon representing the scope.
The authorization server MAY use the referenced icon in any user
interface it presents to a resource owner, for example, for
resource protection monitoring or policy setting.
name OPTIONAL. A human-readable string naming the scope. The
authorization server MAY use this name in any user interface it
presents to a resource owner, for example, for resource protection
monitoring or policy setting. The value of this parameter MAY be
internationalized, as described in Section 2.2 of [RFC7591].
For example, this scope description characterizes a scope that
involves printing (as opposed to, say, creating or editing in some
fashion):
{
"description":"Print out and produce PDF files of photos",
"icon_uri":"http://www.example.com/icons/printer",
"name":"Print"
}
3.2. Resource Registration API
The authorization server MUST support the following five registration
options and MUST require a valid PAT for access to them; any other
operations are undefined by this specification. Here, _rreguri_
stands for the resource registration endpoint and __id_ stands for
the authorization server-assigned identifier for the web resource
corresponding to the resource at the time it was created, included
within the URL returned in the Location header. Each operation is
defined in its own section below.
o Create resource description: POST _rreguri_/
o Read resource description: GET _rreguri_/__id_
o Update resource description: PUT _rreguri_/__id_
o Delete resource description: DELETE _rreguri_/__id_
o List resource descriptions: GET _rreguri_/
Within the JSON body of a successful response, the authorization
server includes common parameters, possibly in addition to method-
specific parameters, as follows:
Maler, et al. Expires August 17, 2019 [Page 13]
Internet-Draft February 2019
_id REQUIRED (except for the Delete and List methods). A string
value repeating the authorization server-defined identifier for
the web resource corresponding to the resource. Its appearance in
the body makes it readily available as an identifier for various
protected resource management tasks.
user_access_policy_uri OPTIONAL. A URI that allows the resource
server to redirect an end-user resource owner to a specific user
interface within the authorization server where the resource owner
can immediately set or modify access policies subsequent to the
resource registration action just completed. The authorization
server is free to choose the targeted user interface, for example,
in the case of a deletion action, enabling the resource server to
direct the end-user to a policy-setting interface for an overall
"folder" resource formerly "containing" the deleted resource (a
relationship the authorization server is not aware of), to enable
adjustment of related policies.
If the request to the resource registration endpoint is incorrect,
then the authorization server instead responds as follows (see
Section 6 for information about error messages):
o If the referenced resource cannot be found, the authorization
server MUST respond with an HTTP 404 (Not Found) status code and
MAY respond with a "not_found" error code.
o If the resource server request used an unsupported HTTP method,
the authorization server MUST respond with the HTTP 405 (Method
Not Allowed) status code and MAY respond with an
"unsupported_method_type" error code.
o If the request is missing a required parameter, includes an
invalid parameter value, includes a parameter more than once, or
is otherwise malformed, the authorization server MUST respond with
the HTTP 400 (Bad Request) status code and MAY respond with an
"invalid_request" error code.
3.2.1. Create Resource Description
Adds a new resource description to the authorization server using the
POST method. If the request is successful, the resource is thereby
registered and the authorization server MUST respond with an HTTP 201
status message that includes a "Location" header and an "_id"
parameter.
Maler, et al. Expires August 17, 2019 [Page 14]
Internet-Draft February 2019
Form of a create request, with a PAT in the header:
POST /rreg/ HTTP/1.1 Content-Type: application/json
Authorization: Bearer MHg3OUZEQkZBMjcx
...
{
"resource_scopes":[
"read-public",
"post-updates",
"read-private",
"http://www.example.com/scopes/all"
],
"icon_uri":"http://www.example.com/icons/sharesocial.png",
"name":"Tweedl Social Service",
"type":"http://www.example.com/rsrcs/socialstream/140-compatible"
}
Form of a successful response, also containing an optional
"user_access_policy_uri" parameter:
HTTP/1.1 201 Created
Content-Type: application/json
Location: /rreg/KX3A-39WE
...
{
"_id":"KX3A-39WE",
"user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"
}
3.2.2. Read Resource Description
Reads a previously registered resource description using the GET
method. If the request is successful, the authorization server MUST
respond with an HTTP 200 status message that includes a body
containing the referenced resource description, along with an "_id"
parameter.
Form of a read request, with a PAT in the header:
GET /rreg/KX3A-39WE HTTP/1.1
Authorization: Bearer MHg3OUZEQkZBMjcx
...
Maler, et al. Expires August 17, 2019 [Page 15]
Internet-Draft February 2019
Form of a successful response, containing all the parameters that
were registered as part of the description:
HTTP/1.1 200 OK
Content-Type: application/json
...
{
"_id":"KX3A-39WE",
"resource_scopes":[
"read-public",
"post-updates",
"read-private",
"http://www.example.com/scopes/all"
],
"icon_uri":"http://www.example.com/icons/sharesocial.png",
"name":"Tweedl Social Service",
"type":"http://www.example.com/rsrcs/socialstream/140-compatible"
}
3.2.3. Update Resource Description
Updates a previously registered resource description, by means of a
complete replacement of the previous resource description, using the
PUT method. If the request is successful, the authorization server
MUST respond with an HTTP 200 status message that includes an "_id"
parameter.
Form of an update request adding a "description" parameter to a
resource description that previously had none, with a PAT in the
header:
PUT /rreg/9UQU-DUWW HTTP/1.1
Content-Type: application/json
Authorization: Bearer 204c69636b6c69
...
{
"resource_scopes":[
"http://photoz.example.com/dev/scopes/view",
"public-read"
],
"description":"Collection of digital photographs",
"icon_uri":"http://www.example.com/icons/sky.png",
"name":"Photo Album",
"type":"http://www.example.com/rsrcs/photoalbum"
}
Maler, et al. Expires August 17, 2019 [Page 16]
Internet-Draft February 2019
Form of a successful response, not containing the optional
"user_access_policy_uri" parameter:
HTTP/1.1 200 OK
...
{
"_id":"9UQU-DUWW"
}
3.2.4. Delete Resource Description
Deletes a previously registered resource description using the DELETE
method. If the request is successful, the resource is thereby
deregistered and the authorization server MUST respond with an HTTP
200 or 204 status message.
Form of a delete request, with a PAT in the header:
DELETE /rreg/9UQU-DUWW
Authorization: Bearer 204c69636b6c69
...
Form of a successful response:
HTTP/1.1 204 No content
...
3.2.5. List Resource Descriptions
Lists all previously registered resource identifiers for this
resource owner using the GET method. The authorization server MUST
return the list in the form of a JSON array of "_id" string values.
The resource server can use this method as a first step in checking
whether its understanding of protected resources is in full
synchronization with the authorization server's understanding.
Form of a list request, with a PAT in the header:
GET /rreg/ HTTP/1.1
Authorization: Bearer 204c69636b6c69
...
Maler, et al. Expires August 17, 2019 [Page 17]
Internet-Draft February 2019
Form of a successful response:
HTTP/1.1 200 OK
...
[
"KX3A-39WE",
"9UQU-DUWW"
]
4. Permission Endpoint
The permission endpoint defines a means for the resource server to
request one or more permissions (resource identifiers and
corresponding scopes) with the authorization server on the client's
behalf, and to receive a permission ticket in return, in order to
respond as indicated in Section 3.2 of [UMAGrant]. The resource
server uses this endpoint on the following occasions:
o After the client's initial resource request without an access
token
o After the client's resource request that was accompanied by an
invalid RPT or a valid RPT that had insufficient permissions
associated with it
The use of the permission endpoint is illustrated in Figure 3, with a
request and a success response shown.
Maler, et al. Expires August 17, 2019 [Page 18]
Internet-Draft February 2019
authorization resource
client server server
| | |
|Request resource (no or insufficient |
|access token) | |
|--------------------------------------->|
| | |
| |*PROTECTION API: |
| |*Permission endpoint |
| | |
| |*Request permissions |
| |(POST) |
| |<--------------------|
| |*201 Created with |
| |permission ticket |
| |-------------------->|
| | |
|401 response with permission ticket, |
|authz server location |
|<---------------------------------------|
Figure 3: Permission Endpoint: Request and Success Response
The PAT provided in the API request enables the authorization server
to map the resource server's request to the appropriate resource
owner. It is only possible to request permissions for access to the
resources of a single resource owner, protected by a single
authorization server, at a time.
In its response, the authorization server returns a permission ticket
for the resource server to give to the client that represents the
same permissions that the resource server requested.
The process of choosing what permissions to request from the
authorization server may require interpretation and mapping of the
client's resource request. The resource server SHOULD request a set
of permissions with scopes that is reasonable for the client's
resource request. The resource server MAY request multiple
permissions, and any permission MAY have zero scopes associated with
it. Requesting multiple permissions might be appropriate, for
example, in cases where the resource server expects the requesting
party to need access to several related resources if they need access
to any one of the resources (see Section 3.3.4 of [UMAGrant] for an
example). Requesting a permission with no scopes might be
appropriate, for example, in cases where an access attempt involves
an API call that is ambiguous without further context (role-based
scopes such as "user" and "admin" could have this ambiguous quality,
and an explicit client request for a particular scope at the token
Maler, et al. Expires August 17, 2019 [Page 19]
Internet-Draft February 2019
endpoint later can clarify the desired access). The resource server
SHOULD document its intended pattern of permission requests in order
to assist the client in pre-registering for and requesting
appropriate scopes at the authorization server. See [UMA-Impl] for a
discussion of permission request patterns.
Note: In order for the resource server to know which authorization
server to approach for the permission ticket and on which resource
owner's behalf (enabling a choice of permission endpoint and PAT), it
needs to derive the necessary information using cues provided by the
structure of the API where the resource request was made, rather than
by an access token. Commonly, this information can be passed through
the URI, headers, or body of the client's request. Alternatively,
the entire interface could be dedicated to the use of a single
resource owner and protected by a single authorization server.
4.1. Resource Server Request to Permission Endpoint
The resource server uses the POST method at the permission endpoint.
The body of the HTTP request message contains a JSON object for
requesting a permission for single resource identifier, or an array
of one or more objects for requesting permissions for a corresponding
number of resource identifiers. The object format in both cases is
derived from the resource description format specified in
Section 3.1; it has the following parameters:
resource_id REQUIRED. The identifier for a resource to which the
resource server is requesting a permission on behalf of the
client. The identifier MUST correspond to a resource that was
previously registered.
resource_scopes REQUIRED. An array referencing zero or more
identifiers of scopes to which the resource server is requesting
access for this resource on behalf of the client. Each scope
identifier MUST correspond to a scope that was previously
registered by this resource server for the referenced resource.
Maler, et al. Expires August 17, 2019 [Page 20]
Internet-Draft February 2019
Example of an HTTP request for a single permission at the
authorization server's permission endpoint, with a PAT in the header:
POST /perm HTTP/1.1
Content-Type: application/json
Host: as.example.com
Authorization: Bearer 204c69636b6c69
...
{
"resource_id":"112210f47de98100",
"resource_scopes":[
"view",
"http://photoz.example.com/dev/actions/print"
]
}
Maler, et al. Expires August 17, 2019 [Page 21]
Internet-Draft February 2019
Example of an HTTP request for multiple permissions at the
authorization server's permission endpoint, with a PAT in the header:
POST /perm HTTP/1.1
Content-Type: application/json
Host: as.example.com
Authorization: Bearer 204c69636b6c69
...
[
{
"resource_id":"7b727369647d",
"resource_scopes":[
"view",
"crop",
"lightbox"
]
},
{
"resource_id":"7b72736964327d",
"resource_scopes":[
"view",
"layout",
"print"
]
},
{
"resource_id":"7b72736964337d",
"resource_scopes":[
"http://www.example.com/scopes/all"
]
}
]
4.2. Authorization Server Response to Resource Server on Permission
Request Success
If the authorization server is successful in creating a permission
ticket in response to the resource server's request, it responds with
an HTTP 201 (Created) status code and includes the "ticket" parameter
in the JSON-formatted body. Regardless of whether the request
contained one or multiple permissions, only a single permission
ticket is returned.
Maler, et al. Expires August 17, 2019 [Page 22]
Internet-Draft February 2019
For example:
HTTP/1.1 201 Created
Content-Type: application/json
...
{
"ticket":"016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}
4.3. Authorization Server Response to Resource Server on Permission
Request Failure
If the resource server's permission registration request is
authenticated properly but fails due to other reasons, the
authorization server responds with an HTTP 400 (Bad Request) status
code and includes one of the following error codes (see Section 6 for
more information about error codes and responses):
invalid_resource_id At least one of the provided resource
identifiers was not found at the authorization server.
invalid_scope At least one of the scopes included in the request was
not registered previously by this resource server for the
referenced resource.
5. Token Introspection Endpoint
When the client makes a resource request accompanied by an RPT, the
resource server needs to determine whether the RPT is active and, if
so, its associated permissions. Depending on the nature of the RPT
and operative caching parameters, the resource server MAY take any of
the following actions as appropriate to determine the RPT's status:
o Introspect the RPT at the authorization server using the OAuth
token introspection endpoint (defined in [RFC7662] and this
section) that is part of the protection API. The authorization
server's response contains an extended version of the
introspection response. If the authorization server supports this
specification's version of the token introspection endpoint, it
MUST declare the endpoint in its discovery document (see
Section 2) and support this extended version of the response.
o Use a cached copy of the token introspection response if allowed
(see Section 4 of [RFC7662]).
o Validate the RPT locally if it is self-contained.
Maler, et al. Expires August 17, 2019 [Page 23]
Internet-Draft February 2019
The use of the token introspection endpoint is illustrated in
Figure 4, with a request and a success response shown.
authorization resource
client server server
| | |
|Resource request with RPT |
|----------------------------------------->|
| | |
| |*PROTECTION API: |
| |*Introspection endpoint|
| | |
| |*Request to introspect |
| |token (POST) |
| |<----------------------|
| |*Response with token |
| |introspection object |
| |---------------------->|
| | |
|Protected resource |
|<-----------------------------------------|
Figure 4: Token Introspection Endpoint: Request and Success Response
The authorization server MAY support both UMA-extended and non-UMA
introspection requests and responses.
5.1. Resource Server Request to Token Introspection Endpoint
Note: In order for the resource server to know which authorization
server, PAT (representing a resource owner), and endpoint to use in
making the token introspection API call, it may need to interpret the
client's resource request.
Example of the resource server's request to the authorization server
for introspection of an RPT, with a PAT in the header:
POST /introspect HTTP/1.1
Host: as.example.com
Authorization: Bearer 204c69636b6c69
...
token=sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv
Because an RPT is an access token, if the resource server chooses to
supply a token type hint, it would use a "token_type_hint" of
"access_token".
Maler, et al. Expires August 17, 2019 [Page 24]
Internet-Draft February 2019
5.1.1. Authorization Server Response to Resource Server on Token
Introspection Success
The authorization server's response to the resource server MUST use
[RFC7662], responding with a JSON object with the structure dictated
by that specification, extended as follows.
If the introspection object's "active" parameter has a Boolean value
of "true", then the object MUST NOT contain a "scope" parameter, and
MUST contain an extension parameter named "permissions" that contains
an array of objects, each one (representing a single permission)
containing these parameters:
resource_id REQUIRED. A string that uniquely identifies the
protected resource, access to which has been granted to this
client on behalf of this requesting party. The identifier MUST
correspond to a resource that was previously registered as
protected.
resource_scopes REQUIRED. An array referencing zero or more strings
representing scopes to which access was granted for this resource.
Each string MUST correspond to a scope that was registered by this
resource server for the referenced resource.
exp OPTIONAL. Integer timestamp, measured in the number of seconds
since January 1 1970 UTC, indicating when this permission will
expire. If the token-level "exp" value pre-dates a permission-
level "exp" value, the token-level value takes precedence.
iat OPTIONAL. Integer timestamp, measured in the number of seconds
since January 1 1970 UTC, indicating when this permission was
originally issued. If the token-level "iat" value post-dates a
permission-level "iat" value, the token-level value takes
precedence.
nbf OPTIONAL. Integer timestamp, measured in the number of seconds
since January 1 1970 UTC, indicating the time before which this
permission is not valid. If the token-level "nbf" value post-
dates a permission-level "nbf" value, the token-level value takes
precedence.
Maler, et al. Expires August 17, 2019 [Page 25]
Internet-Draft February 2019
Example of a response containing the introspection object with the
"permissions" parameter containing a single permission:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
...
{
"active":true,
"exp":1256953732,
"iat":1256912345,
"permissions":[
{
"resource_id":"112210f47de98100",
"resource_scopes":[
"view",
"http://photoz.example.com/dev/actions/print"
],
"exp":1256953732
}
]
}
6. Error Messages
If a request is successfully authenticated, but is invalid for
another reason, the authorization server produces an error response
by supplying a JSON-encoded object with the following members in the
body of the HTTP response:
error REQUIRED except as noted. A single error code. Values for
this parameter are defined throughout this specification.
error_description OPTIONAL. Human-readable text providing
additional information.
error_uri OPTIONAL. A URI identifying a human-readable web page
with information about the error.
Maler, et al. Expires August 17, 2019 [Page 26]
Internet-Draft February 2019
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
...
{
"error": "invalid_resource_id",
"error_description": "Permission request failed with bad resource ID.",
"error_uri": "https://as.example.com/uma_errors/invalid_resource_id"
}
7. Security Considerations
This specification inherits the security considerations of [UMAGrant]
and has the following additional security considerations.
In the context of federated authorization, more parties may be
operating and using UMA software entities, and thus may need to
establish agreements about the parties' rights and responsibilities
on a legal or contractual level, as discussed in Section 5.8 of
[UMAGrant].
The protection API is secured by means of OAuth (through the use of
the PAT). Therefore, it is susceptible to OAuth threats.
8. Privacy Considerations
This specification inherits the privacy considerations of [UMAGrant]
and has the following additional privacy considerations.
As noted in Section 6.1 of [UMAGrant], the authorization server
should apply authorization, security, and time-to-live strategies in
a way that favors resource owner needs and action so that removal of
authorization grants is achieved in a timely fashion. PATs are
another construct to which it can apply these strategies.
In the context of federated authorization, more parties may be
operating and using UMA software entities, and thus may need to
establish agreements about mutual rights, responsibilities, and
common interpretations of UMA constructs for consistent and expected
software behavior, as discussed in Section 6.4 of [UMAGrant].
The authorization server comes to be in possession of resource
details that may reveal information about the resource owner, which
the authorization server's trust relationship with the resource
server is assumed to accommodate. The more information about a
resource that is registered, the more risk of privacy compromise
there is through a less-trusted authorization server. For example,
Maler, et al. Expires August 17, 2019 [Page 27]
Internet-Draft February 2019
if resource owner Alice introduces her electronic health record
resource server to an authorization server in the cloud, the
authorization server may come to learn a great deal of detail about
Alice's health information just so that she can control access by
others to that information.
9. IANA Considerations
This document makes the following requests of IANA.
9.1. OAuth 2.0 Authorization Server Metadata Registry
This specification registers OAuth 2.0 authorization server metadata
defined in Section 2, as required by Section 7.1 of [OAuthMeta].
9.1.1. Registry Contents
o Metadata name: "permission_endpoint"
o Metadata description: endpoint metadata
o Change controller: Kantara Initiative User-Managed Access Work
Group - staff@kantarainitiative.org
o Specification document: Section 2 in this document
o Metadata name: "resource_registration_endpoint"
o Metadata description: endpoint metadata
o Change controller: Kantara Initiative User-Managed Access Work
Group - staff@kantarainitiative.org
o Specification document: Section 2 in this document
9.2. OAuth Token Introspection Response Registration
This specification registers the name defined in Section 5.1.1, as
required by Section 3.1 of [RFC7662].
9.2.1. Registry Contents
o Name: "permissions"
o Description: array of objects, each describing a scoped, time-
limitable permission for a resource
Maler, et al. Expires August 17, 2019 [Page 28]
Internet-Draft February 2019
o Change controller: Kantara Initiative User-Managed Access Work
Group - staff@kantarainitiative.org
o Specification document: Section 5.1.1 in this document
10. Acknowledgments
The following people made significant text contributions to the
specification:
o Paul C. Bryan, ForgeRock US, Inc. (former editor)
o Domenico Catalano, Oracle (former author)
o Mark Dobrinic, Cozmanova
o George Fletcher, AOL
o Thomas Hardjono, MIT (former editor)
o Andrew Hindle, Hindle Consulting Limited
o Lukasz Moren, Cloud Identity Ltd
o James Phillpotts, ForgeRock
o Christian Scholz, COMlounge GmbH (former editor)
o Mike Schwartz, Gluu
o Cigdem Sengul, Nominet UK
o Jacek Szpot, Newcastle University
Additional contributors to this specification include the Kantara UMA
Work Group participants, a list of whom can be found at
[UMAnitarians].
11. References
11.1. Normative References
[BCP195] Sheffer, Y., "Recommendations for Secure Use of Transport
Layer Security (TLS) and Datagram Transport Layer Security
(DTLS)", May 2015, <https://tools.ietf.org/html/bcp195>.
Maler, et al. Expires August 17, 2019 [Page 29]
Internet-Draft February 2019
[OAuthMeta]
Jones, M., "OAuth 2.0 Authorization Server Metadata",
November 2017, <https://tools.ietf.org/html/
draft-ietf-oauth-discovery-08>.
[OIDCCore]
Sakimura, N., "OpenID Connect Core 1.0 incorporating
errata set 1", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/info/rfc7009>.
Maler, et al. Expires August 17, 2019 [Page 30]
Internet-Draft February 2019
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[UMAGrant]
Maler, E., "User-Managed Access (UMA) Grant for OAuth 2.0
Authorization", January 2019,
<https://docs.kantarainitiative.org/uma/
rec-oauth-uma-grant-2.0.html>.
11.2. Informative References
[UMA-Impl]
Maler, E., "UMA Implementer's Guide", 2017,
<https://kantarainitiative.org/confluence/display/uma/
UMA+Implementer%27s+Guide>.
[UMAnitarians]
Maler, E., "UMA Participant Roster", 2017,
<https://kantarainitiative.org/confluence/display/uma/
Participant+Roster>.
Authors' Addresses
Eve Maler (editor)
ForgeRock
Email: eve.maler@forgerock.com
Maciej Machulak
HSBC
Email: maciej.p.machulak@hsbc.com
Maler, et al. Expires August 17, 2019 [Page 31]
Internet-Draft February 2019
Justin Richer
Bespoke Engineering
Email: justin@bspk.io
Thomas Hardjono
MIT
Email: hardjono@mit.edu
Maler, et al. Expires August 17, 2019 [Page 32]