Scopes and scope management
OAuth allows you to constrain the privileges associated with an access token, and scopes allow you to define the privileges requested and granted.
Static scopes versus dynamic scopes
include::ROOT:partial$pf_rc_staticanddynamicscopesintro.adoc[tags=pf_ph_staticAndDynamicScopesIntro]For example, when ah a requested scope of read_bank_account_txn:1234
, PingFederate can match the requested scope to the dynamic scope pattern of read_bank_account_txn:*
and can issue an access token with the requested scope of read_bank_account_txn:1234
.
Scope groups
For ease of management and subsequent client interactions, PingFederate has the capability to create multiple groups of static scopes. A client can reference a scope group in applicable OAuth 2.0 protocol interactions. When authorized, clients can subsequently request access tokens with fewer permissions by presenting to the token endpoint a refresh token and the desired subset of scopes.
A scope group must contain at least one static scope, and multiple sub scopes are allowed. Multiple scope groups can share the same set of sub scopes. However, no scope group can contain another scope group or the default scope.
Scope group expansion
An authorization request can include one or more scope values. If the request is authorized, PingFederate issues an access token to the client. When the client brings the access token to a resource server to access protected resources, the resource server may contact PingFederate to validate the access tokens. Scope groups are not expanded in JSON web token (JWT)-based access tokens or token introspection responses by default. You can optionally enable scope group expansion per access token management instance.
Regardless of whether you choose to expand scope groups, the Request for Approval window always presents the description of the requested scope groups, if any. |
Common scopes and exclusive scopes
PingFederate has the flexibility to manage common and exclusive scopes and scope groups.
- Common scopes and scope groups
-
Common scopes and scope groups are optional. If defined, they are available to all clients by default. As needed, you can restrict individual clients to a subset of common scopes or scope groups in their configurations.Clients created via the Dynamic Client Registration protocol can also be restricted to a subset of common scopes or scope groups based on the configuration on the Scope Constraints tab in System → OAuth Settings → Client Settings. The Scope Constraints configuration is shared across all clients registered through dynamic client registration. If a certain client requires a different set of common scopes or scope groups, modify the client configuration by using the administrative console, the administrative API, or the OAuth Client Management Service after the client has been created.
- Exclusive scopes and scope groups
-
Exclusive scopes and scope groups are optional. If defined, they are restricted from all clients by default. As needed, you can configure individual clients to allow a subset of exclusive scopes or scope groups in their configurations.Clients created with the Dynamic Client Registration protocol can also be configured to allow a subset of exclusive scopes or scope groups based on the Scope Constraints tab on the System → OAuth Settings → Client Settings window. The Scope Constraints configuration is shared across all clients registered via dynamic client registration. If a certain client requires a different set of exclusive scopes or scope groups, modify the client configuration by using the administrative console, the administrative API, or the OAuth Client Management Service after the client has been created.
A scope or scope group is either a common scope or group, or an exclusive scope or group. Duplicate scopes and scope groups are not allowed. Scope and scope group values are case-sensitive. |
Create scopes that are intended for the majority of clients as common scopes. Create scopes that should be limited to the minority of clients as exclusive scopes. |
OpenID Connect
If one or more clients support the OpenID Connect standard, add the following scopes for the purpose of requesting specific sets of claims from the OpenID Provider:
-
openid
-
address
-
email
-
phone
-
profile
If most clients are allowed to use these scopes, create them as common scopes. |
Per-client scope management
You can manage scope access on a client-to-client basis. The client settings are Restrict Common Scopes and Exclusive Scopes.
- Restrict Common Scopes
-
This setting determines whether all common scopes and scope groups should be made available to the client, or only a select few.When selected, the administrative console displays a list of existing common scopes and scope groups. Choose the common scopes and scope groups that are intended for the client. The rest, as well as any future common scopes and scope groups, become invalid for the client. If the client tries to use such scope or scope group, it will receive an
invalid_scope
error message from PingFederate.When cleared, all existing and future common scopes and scope groups are available to the client. This is the default behavior. - Exclusive Scopes
-
This setting determines whether any exclusive scopes and exclusive scope groups should be made available to the client.When selected, the administrative console displays a list of existing exclusive scopes and scope groups. Choose the exclusive scopes and scope groups that are intended for the client. The rest, as well as any future exclusive scopes and scope groups, become invalid for the client. If the client tries to use such scope or scope group, it will receive an
invalid_scope
error message from PingFederate.When cleared, no exclusive scopes and scope groups are available to the client. This is the default behavior.
Both settings impact dynamic scope evaluation. For more information, see Dynamic scope evaluation and per-client scope management. |
Dynamic scopes
A dynamic scope is defined by using a text value with a variable component represented by an asterisk (*
). PingFederate supports three dynamic scope patterns:
-
A prefix followed by a wildcard, for example:
prefixTextValue*
-
A wildcard followed by a suffix, for example:
*suffixTextValue
-
A wildcard placed between a prefix and a suffix, for example:
prefixTextValue*suffixTextValue
PingFederate only allows one variable component. Backslashes (\
) and double quotation marks ("
) are not allowed in the prefix or the suffix.Multiple dynamic scopes are supported in conjunction with any number of static scopes and scope groups.
Dynamic scope evaluation
When a client sends an authorization or token request with a list of desired scopes, PingFederate validates the requested scopes against its configurations.
If PingFederate finds no match for the requested scopes, it returns an invalid_scope
error message to the client.
If PingFederate matches the requested scope to an existing static scope or scope group, it checks the client configuration to determine whether such static scope or scope group is valid for the client. If it is, PingFederate proceeds further. For example, if PingFederate is configured to handle consent approval, it presents to the user the Request for Approval window with the description associated with the matched static scope or scope group. If PingFederate should issue an access token, the token is issued with the requested scope. If such static scope or scope group is not valid for the client, PingFederate returns an invalid_scope
error message to the client.
If PingFederate finds no exact match but finds a partial match to one or more dynamic scopes, the partial match with the highest number of matched characters in the prefix, suffix, or both is the matched dynamic scope. In the event that two partial matches tie, the partial match with the highest number of characters matched in the prefix is the matched dynamic scope. PingFederate then checks the client configuration to determine whether such dynamic scope is valid for the client. If it is, PingFederate proceeds further. Otherwise, PingFederate returns an invalid_scope
error message to the client. If PingFederate should issue an access token, the token is issued with the requested scope, not the matched dynamic scope pattern.
Example
For example, you add the following dynamic scopes:
Common Scopes | Exclusive Scopes |
---|---|
|
|
|
|
|
|
|
|
|
|
|
You also add a client without any common scope restrictions. This client can access all common scopes.
The following table illustrates the expected results when the client sends an authorization request with these scopes:
-
xy#1
-
xy#12
-
xy#123
-
xy#1234
-
xy#12345
-
xy#123456
-
xyz
-
z123
-
z12345
-
abc#123
Requested scope | Matched dynamic scope | Variable component from the requested scope |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The minimum length of the variable component is one character. If the variable component contains two or more characters, it may also contain the asterisk character as well. Given the same common dynamic scopes and the same client configuration, requested scopes of xyQ123
, xy*Q123
, xyQ*123
, xy**Q*123
will be matched as in the following table.
Requested scope | Matched dynamic scope | Variable component from the requested scope |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
If the client sends an authorization request with a requested scope of xy*123
, it will receive an invalid_scope
error from PingFederate.
==
Dynamic scope evaluation and per-client scope management
Depending on the configured dynamic scope patterns and if they are defined as common or exclusive dynamic scopes, per-client scope management settings can impact the results of scope evaluation.
The Restrict Common Scopes setting determines whether all common scopes and scope groups are available to the client, or only a select few. Use this setting to restrict certain common dynamic scopes.
The Exclusive Scopes setting determines whether any exclusive scopes and scope groups are available to the client. When this check box is not selected, PingFederate does not consider any exclusive dynamic scopes or any exclusive static scopes and scope groups when trying to match a requested scope against a list of configured scopes and scope groups. When the check box is selected, all exclusive scopes and scope groups are considered. If PingFederate matches a requested scope to an exclusive dynamic scope and such scope is not available to the client, PingFederate returns an invalid_scope
error message to the client. This remains true for a lesser partial match to an available common dynamic scope.
Example
For example, you update your previous sample scope configuration as in the following table.
Common Scopes | Exclusive Scopes |
---|---|
|
|
|
|
|
|
|
|
|
The following table describes the results when the client sends an authorization request with a requested scope of xy#123
.
Per-client scope management settings | Result | Variable component from the requested scope |
---|---|---|
Restrict Common Scopes
Exclusive Scopes
|
PingFederate matches the requested scope of The exclusive dynamic scope of |
|
Restrict Common Scopes
Exclusive Scopes
No other exclusive scope is selected. |
PingFederate returns an |
Not applicable. |
Restrict Common Scopes
Exclusive Scopes
It does not matter if any other exclusive scope is selected. |
PingFederate matches the requested scope of |
|
Restrict Common Scopes
No other common scope is selected. Exclusive Scopes
|
PingFederate returns an The exclusive dynamic scope of |
Not applicable. |
Restrict Common Scopes
It does not matter if any other common scope is selected. Exclusive Scopes
It does not matter if any other exclusive scope is selected. |
PingFederate matches the requested scope of |
|
Description for scopes and scope groups
When defining a scope or a scope group, enter a value and a description for the scope or the scope group. This description helps you identify the purpose of the scope or scope group at a later time. If PingFederate is configured to handle consent approval, the Scope Description, Scope Group Description, and Default Scope Description fields determines the text that appears on the Request for Approval window.
- Default scope
-
The default scope is the implied permissions when no scope and scope group values are indicated, or in addition to any scope or scope group values.If your organization requires a localized description, enter a unique alias in the Default Scope Description field, such as
oauth.approval.page.template.defaultScope
. Insert the same alias with the desired localized text in the applicable language resource files, located in<pf_install>/pingfederate/server/default/conf/language-packs
. - Static scopes and scope groups
-
You can enter simple descriptions or localize the descriptions by using the PingFederate localization framework.
- Dynamic scopes
-
You can enter simple descriptions. You can also use a mix of text and scope-description variables.
${scope}
represents the requested scope, and${scope-var}
represents the variable component found in the requested scope.Suppose you added a dynamic scope with a pattern ofdynaGet67*10
and a scope description of${scope} contains ${scope-var}
. If a client requests a scope value ofdynaGet67eight910
, the resulting scope description isdynaGet67eight910 contains eight9
. (eight9
is the variable component found in the requested scope.)If your organization requires a localized description, enter a unique alias in the Scope Description field (for example,oauth.approval.page.template.someDynamicScope
). Then insert the same alias with the desired localized text in the applicable language resource files, located in the<pf_install>/pingfederate/server/default/conf/language-packs
directory. You may also use scope-description variables as part of the localized text.
Both scope-description variables are intended for dynamic scopes only. When they are used as description for static scopes or a scope groups, PingFederate shows them on the Request for Approval window. |
Dynamic scopes and consent user interface
The default consent approval process and user interface in PingFederate are capable of handling dynamic scopes and their scope descriptions. While the scope description and the optional scope-description variables provide the basic controls to describe a given scope, PingFederate also supports the use of an external web application to prompt for authorization consent. This allows you to retrieve additional information specific to the users and apply application-specific scope-processing logic.
Coordinating with developers
Regardless of whether a static scope, a scope group, or a dynamic scope is created as common or exclusive, a scope or a scope group represents access to a resource or API on the RS. Applicable scope or scope group values require coordination with developers that are familiar with the details of the RS OAuth implementation. For clients supporting the OpenID Connect protocol, you can direct the developers to your PingFederate OpenID Provider configuration endpoint to retrieve a list of common scopes and common scope groups.
The OpenID Provider configuration endpoint does not return exclusive static scopes, exclusive scope groups, common dynamic scopes, and exclusive dynamic scopes by default. You can optionally customize the response to include such scopes and scope groups as needed. |
Related links
-
.net/specs/openid-connect-core-1_0.html//[OpenID Connect, Requesting Claims using Scope Values (openid.net/specs/openid-connect-core-1_0.html#ScopeClaims)]
-
Customizing the OpenID Provider configuration endpoint response