- PF27 tutorial: Configure OAuth scopes and organize client permissions in PingFederate.
- Core concept: A scope limits the access rights represented by an authorization request or token.
- Scope types: Use static values for fixed permissions and dynamic values for variable resource patterns.
- Best practice: Keep common, exclusive, grouped, and default scopes clearly separated.
- Next step: Test scope behavior during authorization code flow and client configuration.
PF27 tutorial: Understanding Scope Management
PF27 tutorial material focuses on scope management in PingFederate and its role in OAuth authorization. A scope represents a subset of access rights granted to a client, resource owner, or delegated authorization request. Rather than giving every client broad access, administrators can define specific permissions such as address access, profile access, or administrative actions.
Video Highlights:
- Scope management locations in the PingFederate administration console.
- Differences between common, exclusive, grouped, and default scopes.
- Static and dynamic scope examples for OAuth requests.
- How scope values influence consent and authorization behavior.
In practical terms, the scope value travels with an authorization request. PingFederate evaluates that value against the scopes configured for the client and authorization server. The resulting permissions help determine what the client can request and what the user may approve.
Define scopes around business permissions, not individual interface buttons. A clear scope model is easier to audit, test, and maintain across multiple clients.
Static and Dynamic Scope Configuration
PingFederate supports static and dynamic scopes. A static scope uses a fixed text value, such as read_account, address, or profile. Every request for that scope uses the same name and meaning.
A dynamic scope includes a variable component represented by a wildcard. A pattern such as read_bank_account_txn:* can allow the variable portion to change between requests, depending on the authorization design and validation rules.
Static Scope
Use a fixed value for a stable permission. Examples include address, email, phone, and profile.
Dynamic Scope
Use a variable component when the requested resource or context can change between authorization requests.
Grouped Scope
Combine related permissions under one named group to simplify client configuration and administration.
When creating a scope, provide a meaningful name and a description that explains the permission. For example, an address scope can use a description such as “Address access,” while an admin scope can describe administrative permissions.
Do not use dynamic scopes simply to shorten administration work. Confirm that the variable portion is validated and cannot grant broader access than intended.
Step-by-Step Scope Setup
Use the following process to create a basic scope model in the PingFederate administration console.
Open Scope Management
Sign in to PingFederate and open the system area containing scope management. Review the existing common, exclusive, grouped, and default scope entries before adding new values.
Create Common Scopes
Add fixed permission names such as address, email, phone, or profile. Enter a short description for each permission and mark the value as static unless a variable component is required.
Create a Scope Group
Open common scope groups, provide a unique group name, and add related scopes. A profile-oriented group might contain address, email, and phone permissions.
Review Exclusive Scopes
Use exclusive scopes for permissions that should not be available to a client by default. The client must be explicitly configured to allow these values.
Save and Test
Save the configuration, then test an authorization request with the intended scope parameter. Confirm that the client receives only the permissions configured for its request.
A scope group name must remain unique within the relevant scope configuration. If a name already exists as a common scope, select a different group name to avoid a configuration conflict.
After saving, test both an allowed scope and a restricted scope. This confirms that the client configuration and authorization policy are enforcing the intended boundary.
Client Permissions and Consent Behavior
Scopes are requested by clients during authorization. PingFederate uses the configured scope definitions and client permissions to determine which values are available. Common scopes may be available by default, while exclusive scopes require explicit client authorization.
Default scopes have a special relationship with the consent experience. They can provide a default description or permission selection for the PingFederate authorization approval screen. If a permission is configured as a required default, the user may not be able to remove it from the approval selection.
Use this checklist before moving from configuration to testing:
Scope Review Checklist
- Every scope has a unique and understandable name
- Descriptions explain the permission in plain language
- Dynamic scope patterns have a defined validation strategy
- Exclusive scopes are enabled only for intended clients
- Consent behavior has been tested with realistic authorization requests
Keep scope names consistent across clients, policies, and access token mappings. A naming scheme based on resource and action, such as read_account or write_profile, makes authorization logs easier to interpret.
Treat default permissions carefully. A convenient consent configuration should still make the requested access clear to the resource owner and appropriate for the client.
Testing Strategy and FAQ
A reliable PF27 tutorial workflow ends with focused testing. Start with a simple static scope, then test a scope group, an exclusive scope, and a dynamic scope if your deployment requires one. Record the requested value, the client identity, the consent result, and the final token permissions.
Check these common outcomes:
- A missing scope may indicate that the client is not allowed to request it.
- A rejected dynamic scope may indicate an invalid variable component.
- An unexpected consent selection may result from default scope configuration.
- A broad token may indicate that a group contains more permissions than intended.
- A duplicate name may prevent a group or scope from being saved.
Q: What is a scope in PingFederate?
A scope is a named permission boundary that represents a specific subset of access rights requested by a client and evaluated during authorization.
Q: What is the difference between static and dynamic scopes?
A static scope uses one fixed value, while a dynamic scope includes a variable component that can change between authorization requests.
Q: When should an exclusive scope be used?
Use an exclusive scope for sensitive permissions that should not be available to clients by default. The intended client must be configured to allow it.
Q: Why can a scope group name fail to save?
A scope group name can fail when it conflicts with an existing scope name or violates the uniqueness rules of the current PingFederate configuration.
Begin with the smallest permission set that supports the client task. Add scopes only when the application requirement is clear and the authorization test confirms the expected result.