Is there any good practice when we consider to manage like this data structure on Auth0?

Help
,
1

Hello hello!

We provides SaaS base CRM services which integrated with communication mobile app like LINE(Famous one in Japan.). Because current architecture doesn’t support to manage user identity and associated authorization targets horizontally such as

  • SaaS … A user can log-in
  • Roles … What kind of role they can have on that SaaS
  • Apps … Which apps on target SaaS this user can have operation

So, thinking to migrate current ID and these authorization management architecture with Auth0. (or else, it’s just draft idea raised early stage of planning discussion.)

By going through API docs, architecture scenarios I still couldn’t have draft idea which data better to store on Auth0 as one of User attribute or on our platform separately.

It seems there are these options to use for these user attributes on Auth0,

  • Roles
  • permissions
  • app_metadata
  • user_metadata

But not sure yet, what’s good practice how we use these objects and attributes in our case.

It’s great help for me if you give some suggestions for this case.

Thank you for your sexy kindness in advance po!

2

Hello @roshihy,

Auth0 provides a lot of flexibility here. You can use the core RBAC feature, which is really focussed on managing permissions to APIs.

You can also create your own RBAC capability by storing data in the user’s app_metadata. You’ll want to use app_metadata for this rather than user_metadata. The difference between the two is:

  • user_metadata: the user’s own credentials are sufficient for editing user_metadata
  • app_metadata: only a privileged user can edit app_metadata. The user’s own credentials are NOT sufficient to edit app_metadata

(there’s also the Authorization extension, which shares some features with core RBAC. I believe core RBAC will eventually replace the authorization extension but don’t quote me on that.)

I’ll file that one under lost in translation! :laughing:

Cheers,
Mark

1 Like