Managing Scopes in Delegated Authorization
Use scopes in delegated authorization to limit an application's access to a user's account. Scopes are string values that provide an additional layer of access protections for data within resource servers that can be exposed with an OAuth access token.
Pair a scope name (string value) to data in the resource server, and then register the scope in the Central Auth Server and the service provider. When the service provider requests data from the resource server, it must present a valid access token and have approval for the scopes associated with the data in the resource server.
The following process shows how scopes work:
1. When a user logs into a service provider, the Central Auth Server authorizes the user login session when the user has been authenticated with the IdP
2. Then, the Central Auth Server also presents the user with a Grants Approval page.
The Grants Approval page lists the resources that are associated with the scopes available to the service provider.
3. The user decides whether to allow the service provider access to some or all of the data in the resource server.
4. If approved, the Central Auth Server provides an access token to the service provider and records the grants approval for the appropriate scopes.
5. When a service provider calls to the resource server and requests the protected data, it sends the access token.
6. The resource server verifies the access token with the Central Auth Server; if it is valid and if the AS confirms that the user has granted the SP approval for the scopes that are paired with the protected resource, then the resource server grants access to the data.
You must registers scopes in at least three applications in your SSO framework, in the following order:
1. Central Auth Server (PingFederate) that manages the trust relationship between the two applications
The Central Auth Server administrator should note the scopes that have been registered in the Central Auth Server and coordinate the registration of scopes with resource server and service provider application administrators.
For information about registering scopes in PingFederate, refer to that PingFederate documentation.
2. Resource Server where data resides
You will need to coordinate with the product administrator that is creating the scope in the resource server.
3. Service Provider that requests data
You can choose to register a subset of the scopes that have been registered in the Central Auth Server and resource server. Work with the product administrator or application developer to register the scopes that should be available to the service provider.
 |
Scope names registered in an application must match scopes registered in the Central Auth Server, or a potential lockout of users, including the administrator account, could occur if the application routes authentication through the Central Auth Server. If a scope in the application is misspelled (this includes case-sensitivity) or it is not registered in the Central Auth Server, then the administrator could be prevented from being authenticated by the Central Auth Server when they try to sign in. If a scope registered in the service provider does not exist in the authorization server, then users cannot login — including administrator accounts.
To resolve this issue, add the misspelled or extra scope to the authorization server so the SP administrator can login. Then, remove the problematic scope from the SP and delete the scope from the authorization server.
|
Best Practices and Security Considerations
◦ Consult with security experts in your organization when establishing usage policies for scopes in your SSO deployment. There are steps you can take within each application in your deployment where a scope is registered or configured in order to increase security for the data that is being exchanged. For example, within a resource server you can specify multiple scopes to manage separate sets of data and provide more precise control.
◦ Refer to PingFederate product documentation for advanced security configurations for managing scopes. For example, configuring scopes so that they are associated with separate access tokens.
◦ Refer to OAuth industry best practices to secure scopes. For more information, see OAuth 2.0 Threat Model and Security Considerations.