WSO2 Identity Server is a standard CIAM solution that is fully open source and powered by a strong IAM community. You can freely download WSO2 Identity Server from and try this out. In this article, I will use the latest released Identity Server 5.10.0 and sample pickup-dispatch. here After identifying who the user is with what the user has (authentication), next we need to do access control for the application based on the user's roles (Authorization). Hence Role-Based Access Control is a really important feature for enterprise software applications. The is a mechanism that is used in OAuth2.0 to restrict the access granted to an access token of a user. In WSO2 Identity Server, there are two types of scopes available. scope — These are the scopes that bind to user attributes(WSO2 claims). You can use OIDC scopes to limit access user’s attributes. 1. OIDC scopes eg: If the access token is taken from Scope openid , the user’s full details can be viewed. If scope email is used, the only PRIMARY email address will be visible (This can be configured as shown here ). — These are the scopes that bind to roles (DEFAULT) and permissions (PERMISSION). By default these scopes will be bound to roles, but if you want you can bind these to permissions as well. 2. OAuth2.0 scopes For now, in WSO2 Identity Server Permission binding is used in the internal purpose only In this blog, I will show you how we can use OAuth 2.0 scopes for Role-Based Access Control of a third party application. Step1: Create OAuth 2.0 scopes and bind to roles For OAuth2.0 scopes we do not have a UI option in the management console. But we have rest APIs to create OAuth2.0 scopes with its relevant role binding. Here I am creating a scope called which bound to role called “manager”. You can refer below APIs for the creation of this scope. “write_access” Create OAuth 2.0 scope POST request with Basic authentication. Permission required: * /permission/admin/manage/identity/applicationmgt/create Get details of OAuth 2.0 scopes GET request with Basic authentication. Permission required: * /permission/admin/manage/identity/applicationmgt/view Delete OAuth 2.0 scopes DELETE request with Basic authentication. Permission required: * /permission/admin/manage/identity/applicationmgt/delete For more information on this OAuth 2.0 scope related API calls you can refer our official swagger documentation: https://is.docs.wso2.com/en/latest/develop/oauth2-scope-management-rest-apis/ Step 2: Register a third party application that needs RBAC In this step, I am registering our sample pickup-dispatch application available . here Click on Add Service Providers and register a service provider name called pickup-dispatch. Click on -> and click on configure. Inbound Authentication Configuration OAuth/OpenID Connect Configuration Add the call-back URL Next, enable and update as shown in the below image. role-based scope validator Update the client-id and secrets in the dispatch.properties file in WEB_INF/classes folder of the pickup-dispatch web app. Add the scopes “write_access” to the scope list in the property file and restart the tomcat server to apply the changes. Step 3: Create Users and manager role and try out Here you can create two users called Alex and Bob. A role called a and assign it only to Alex. manager Now we are ready to try out the scenario. You can see, only Alex can access the application, for Bob the authorization will fail. <iframe width= height= src= frameborder= allow= allowfullscreen> "560" "315" "https://www.youtube.com/embed/DF6EUB6kt7s" "0" "accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" </ > iframe I hope you got a better understanding of how OAuth2.0 scope based Access Control works and the difference between two types of scopes available in WSO2 Identity Server.
