My auth flow right now -
Login → Callback URL to my server → check against db for the type of user based on the email → STUCK HERE → redirect to app with updated token
Right now, I just have two types of users - admins and standard.
If a user is registered as a standard, where should I add this information so I can start restricting API access to standard users?
There are a lot of different ways you can handle this depending on what kind of application you’re working with.
In my case I’m dealing with a multi-tenant setup and I’m using the Auth0 Authorization addon for web users, retrieving the users roles and permissions from that API once they’re logged in.
I also deal with some limited machine to machine auth that uses the same permissions list that I configure in an apis scopes. So similar to an individual user having a permission, a particular server might have certain permissions.
It’s probably also possible to create two distinct applications and differentiate their level of access using api scopes, but then you would need to use a different client id to log in an administrator vs a user.
The other option is to handle all that on your side of things rather than depending on Auth0. Auth0 authenticates the user, but doesn’t by default need to handle authorization for the user. All of that could be handled by your own system.
Hi @creamsteak, I’m curious! Do you like having auth0 do that for you? Have you had any regrets of this decision?
If you’d create another multi-tenant app, would you handle authorization by yourself? Or using auth0’s?
Thank you!
Rick
It’s a nice starting point and it helped force me into some kind of structure. We still had to go in and put together our own interface over the top of the auth0 and authorization addon apis to enforce our own business logic. At first we had all permissions being passed along with the token, but then we learned that we just had far too many permissions for that, so now we have to have the backend get the permissions from the api. Then we decided that our permissions are across multiple applications, so we need to enforce that the roles are shared and the permissions match between them. And we also have scripts that periodically sync data to make sure any new tenants information gets carried over.
So it was somewhat useful to have all of that “out of the box” while we were still prototyping, but eventually we ended up having to roll own interface and rules on top of it. It’s also potentially nice if suddenly we want to spin up an entirely different kind of deployment, like create something in angular or add a new backend api that runs in go. There have also been at least a couple problems because we’re somewhat dealing with a moving target because Auth0 seems to change things that might effect a new tenant but not an older one.
Hey there!
Sorry for such delay in response! We’re doing our best in providing the best developer support experience out there, but sometimes the number of incoming questions is just too big for our bandwidth. Sorry for such inconvenience!
Do you still require further assistance from us?