If an API uses an external identity provider, what security decisions still belong inside the application?

Use an external identity provider without losing app authorization

Explains the boundary between OAuth/OIDC identity, application users, claims mapping, roles, and app-specific permissions.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

An identity provider can authenticate the user and issue trusted identity claims. The application still decides what that user can do inside the product: tenant membership, role or capability assignment, resource ownership, subscription status, and feature access. The API should map external identity to an internal user record or membership model rather than scattering identity-provider assumptions everywhere.

Full answer below

Practice focus

OIDC identity, claims mapping, local users, app roles, tenant membership, resource authorization, and trust boundaries.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
External identity providers solve login and identity proofing, but the application still owns many authorization decisions.
An identity provider can authenticate the user and issue trusted identity claims. The application still decides what that user can do inside the product: tenant membership, role or capability assignment, resource ownership, subscription status, and feature access. The API should map external identity to an internal user record or membership model rather than scattering identity-provider assumptions everywhere.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would validate the provider token, issuer, audience, and claims, then map stable identifiers to local users. I would be careful with email as identity because emails can change or be unverified depending on provider settings. App roles and capabilities can be stored inside the application when they depend on product data. If claims from the provider drive access, the system needs a refresh and revocation story when those claims change.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming external login means full app access.
Using email as the only stable identity without checking provider guarantees.
Putting all app permissions into identity-provider roles even when they depend on app data.
No deprovisioning or disabled-user behavior.

If an API uses an external identity provider, what security decisions still belong inside the application?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant

Tech stacks

Skill areas

Suggest an improvement