Do I need to handle role mapping at the identity provider level or in my app?

It depends on where you want the source of truth to live, but in most systems the answer is:

• Handle authentication at the identity provider (IdP)
• Handle application authorization/mapping in your app

Rule of thumb

Put role mapping in the IdP if:

• The same roles are used across many apps
• You want centralized administration
• Roles are simple and stable
• Your IdP supports issuing roles/groups/claims cleanly

Examples:

• Azure AD / Entra ID groups
• Okta groups
• Keycloak realm/client roles

In this model, the IdP includes role claims in the token, and your app trusts those claims.

Put role mapping in your app if:

• Roles mean different things in different apps
• You need app-specific permissions
• You need to translate broad identity roles into internal permissions
• You want to avoid coupling business logic to IdP structure

Common pattern:

• IdP says: “user is in group X”
• App maps group X → internal role/permission set

Best practice in many cases

Use a hybrid approach:

• IdP: manage identity and coarse-grained groups/roles
• App: map those claims to app permissions

This avoids making your app depend too tightly on IdP-specific role names while still keeping admin manageable.

Example

If the IdP says:

• group: finance-team

Your app might map that to:

• can_view_invoices
• can_approve_expenses

That way, if the IdP group changes later, only your mapping layer needs adjustment.

Important considerations

• Don’t trust client-side role data; only trust tokens/assertions from the IdP
• Prefer authorization in the backend
• Keep mappings configurable if possible
• If roles are highly dynamic, consider using permissions/scopes rather than hard-coded roles

If you tell me which IdP you’re using (Auth0, Okta, Azure AD, Keycloak, etc.) and what app stack you have, I can suggest the cleanest pattern.