Unclear about OAuth2.0 Roles / Permissions / Identity Providers

Help
,
1

Situation:

I am developing an application which has the concept of users and user permissions, but for which I do not wish to implement authentication. Instead, authentication should be delegated to an external service. This service will provider password reset, 2FA, delegating login to Social logins, creating and removing users etc.

This application in reality consists of a Website, a mobile app, and an API which is accessed by the website backend, as well as the mobile app directly.

Questions:

  1. Concerning role/permission management I seem to have two options:

a) user roles/permissions are not configured in auth0. When passing the access token to the API the API will verify the validity of the access token with auth0, and receive from auth0 some information about the user for whom this access token was issued. The API will then check its database for roles/permission configured for this user.
REASON: I won’t be bound to whatever role/permission system auth0 implements and could swap auth0 with any other oidc provider.

b) user roles/permissions are configured within auth0. When passing the access token to the API the api will verify the validity of the access token with auth0 and receive from auth0 some role/permission information associated with this token.
REASON: Everything related to users resides in auth0

Are both of these options 100% possible within the oauth/oidc standard? Is the method of validating an access token with the authorization server standardized or proprietary? Is one options more “oauth-like” than the other?

  1. In my situation the oauth “client” (mobile app or website backend) and “resource server” (the API) are owned by a single organization. Therefore there is no need to limit the scopes the client should have access to. What scopes should then be requested when logging in to auth0?

Regards

Claude

3

Hi @claude

Welcome to the Auth0 Community!

Thanks for taking the time to describe your question thoroughly.

In my opinion, having the permissions inside a token (option B) may be considered “more OAuth-y”, but I’m sure someone would happily disagree with me there :slightly_smiling_face:.

A few other things to consider:

  • Building your own role/permission dashboard for managing user permissions vs using Auth0’s prebuild dashboard and Dashboard Access by Role.
  • Making additional calls to your DB vs having permissions available directly in the token
  • Being beholden to Auth0’s RBAC feature set vs the flexibility of building your own
  • Future interoperability (like you described above).

I would probably choose to go with Auth0’s built in role/permissions because it will get you up and running really quickly and requires less time maintaining auth infrustructure, but then again…I work here. :grin:

1 Like
4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.