OAuth Scopes scopes, which were introduced from the release version WSO2 API Manager 1.7.0 onwards, allow you to have fine grained access control to API resources based on the user roles. It allows you to define scopes per API and associate defined scopes with API Resourcesresources. OAuth 2.0 bearer tokens will be are obtained for a set of requested scopes and the token obtained will is not be allowed to access any API Resources resources beyond the associated scopes. Refer OAuth Scopes for more informationFor more information, see OAuth Scopes.
API manager uses scopes as a way of defining permissions for a resource. If a resource is assigned a scope, then the token accessing the resource should be generated with that scope. By associating a scope with a role, you can control which users are permitted to have tokens under certain scopes. In this instance, associating a role to a scope seems legitimate.
Validating the role of a requester does not make much sense in some scenarios. For instance, when the scope is used as a means of generating an access token and not for securing a resource (e.g. openId scope). In such situations, scope validation can be extended to skip role validation for certain scopes.
Skipping role validation for scopes
When scopes which cannot be associated to roles are requested, the token should be issued without validating the scope. In WSO2 API Manager, you do this by whitelisting the scope through configuration. Patterns of the whitelisted scopes are specified via a configuration under the
APIKeyValidator element in the
<APIM_HOME>/repository/conf/api-manager.xml file. Scopes that match the pattern are not validated by role and are available to anyone requesting it.
The following steps show a demonstration:
- Start the API Manager server and log into the API Store.
- Create an application. On the My Subscriptions tab for your application, click Generate Keys.
Get the consumer key and consumer secret and create a command to call the token API.
You can simply click the cURL button and select the relevant grant type.
Get the token by calling the token API.
Make sure you include a random scope in the request.
Code Block language xml
curl -k -d "grant_type=password&username=admin&password=admin&scope=some_random_scope" -H "Authorization: Basic WmRFUFBvZmZwYVFnR25ScG5iZldtcUtSS3IwYTpSaG5ocEVJYUVCMEN3T1FReWpiZTJwaDBzc1Vh" -H "Content-Type: application/x-www-form-urlencoded" https://10.100.0.3:8243/token
Along with the token, you receive a response from the server similar to the one below.
You may not see the scope you requested for in this response as it has not been whitelisted yet.
Shut down the server.
To whitelist the scope, add the following under the
<APIKeyValidator>element in the
<APIM_HOME>/repository/conf/api-manager.xmlfile and restart the server.
Code Block language xml
<ScopeWhitelist> <Scope>^device_.*</Scope> <Scope>somerandomscope</Scope> </ScopeWhitelist>
Call the token API using the same request used in step 4. You will receive a response similar to the one below.
You see a successful response along with the whitelisted scope for which you requested.