I’ve spent the past few days trying to wrap my head around Auth0 and its ability to do authentication and authorisation.
I have an existing project which is a Regular Web Application (Application) that I assume uses the System API (API). Anyhow, I need to add authorisation to this existing system.
My thought was to create a custom API since I found a lot of documentation doing it this way. This allows me to enable RBAC and setup permissions and roles. However, after I set this all up I noticed that I will no longer be using the original Regular Web App which contains all the existing users. By this, I mean how the application originally authenticates.
So my question is, how do I go about enabling authorisation to this existing Regular Web App. Do I keep progressing with the custom API and just create a new API call to get the user’s roles and permissions? Or am I way out of scope.
I understand that you have some questions related to Authorization.
To help me better understand your use case, could you please clarify whether you would like to prevent certain users’ access to your Regular Web App based on different roles/permissions?
If not, could you please elaborate on your intended workflow using Authorization?
I want the permissions/roles to be attached to the user on login so then I can do validation of the front-end. For instance, blocking out access to a certain page using the front-end via graying out a button.
So its more validation of the routes of the website.
I also have the intention to use the same permissions and roles to restrict access to my backend API calls. But I’m still waging up the pro’s and con’s considering I may need to setup a proxy since I am using an external API
In this case, you are on track with using RBAC to add authorization Roles and Permissions to your users.
With RBAC, you have the option of using Authorization Core or the Authorization Extension to assign Roles and Permissions to your users.
After assigning Roles and Permissions to your users, they can authenticate onto your application as usual.
The resources the user can access will depend on the Roles/Permissions assigned to them.
You can access this information by enabling RBAC and Add Permissions in the Access Token and determine whether the user has the authorization to access those resources.
Please let me know if you have any questions. I’d be happy to clarify.
I believe I got that part. But I am more confused about how authentication will still work. For example, only the custom API can enable RBAC. So do I no longer using the existing ‘Regular Web Application’ for authenticating the user? Since only the custom API has the attached RBAC permissions?
Because when I switched it over to the custom API, I couldn’t log in with the original users which are all currently stored in the Regular Web Application which I believe uses the Systems API?
First, I want to clarify that you have 2 options for Role-Based Action Control. Both approaches are valid, with the key difference being the usage of an API. Let me explain further:
Using Authorization Core uses an API:
– Use Regular Web App
– Use API
– Configure your web application to request a token using the Authorization Code Flow
– Use this access token to access your secured/restricted resources
When requesting an access token to call the API, the user will authenticate with the audience parameter to reference your API identifier.
The returning access token includes the scope claim that defines those assigned permissions to the users.
All requests that do not include a valid Access Token (expired token, incorrect scopes, etc.) will return an error instead of the desired data.
In this scenario, you will want to continue using your existing Regular Web App to authenticate the users and use that access token to call the API to grant permissions to those resources.
Using Authorization Extension does not use an API:
– Use Regular Web App
– Use Roles/Permissions
– Use Authorization based Rules: To define expected behavior during the login process depending on your users’ Roles/Permissions
With the Authorization Extension, you can store authorization data like groups, roles, or permissions in the outgoing token issued by Auth0. Your application can then consume this information by inspecting the token and take appropriate actions based on the user’s current authorization context.
Generally, in scenarios where having Access Control on your users to restrict access based on Roles/Permissions is desired, using Rules with the Authorization Extension approach is preferred.
Please let me know if this answers all of your questions. I’d be happy to clarify if needed.
