access denied" after sso to a saas app
Troubleshoots SSO sign-in succeeding at the identity provider but the SaaS app showing access denied. Covers app assignment, license, and attribute mapping. Use when Okta or Entra says signed in but the app refuses. Not for IdP-side login failures.
TL;DR
Check that the user is assigned to the app in the IdP admin console and holds a license or seat in the app itself. Then check the SAML/OIDC attribute mappings (especially email and groups). SSO passing while the app denies almost always means assignment or provisioning, not authentication.
The error
Access denied. You do not have permission to access this application.Steps
- In the IdP admin console (Okta Applications or Entra Enterprise Apps), open the app > Assignments and confirm the user or their group is assigned. Expected: assigned. Unassigned users get exactly this error after a successful IdP login.
- Check the app side: does the user have a license/seat? Expected: yes. Many apps deny access when the seat count is exceeded even with valid SSO.
- Check provisioning status if the app uses SCIM. Expected: user provisioned and active. A user assigned in the IdP but never provisioned in the app hits access denied.
- Review the SAML attribute mappings: NameID format and email attribute. Expected: they match what the app expects (usually email as NameID). A mismatched NameID creates a phantom identity the app rejects.
- Test with the IdP's "preview the SAML assertion" tool if available. Expected: attributes look correct. Fix mappings, then have the user retry.
When to use
- IdP login succeeds, app shows access denied
- New app rollout with assignment gaps
When not to use
- IdP login itself fails (fix authentication first)
- App is down for everyone (outage, not access)
Compatibility
- Okta and Entra ID SAML/OIDC app integrations; SCIM-provisioned apps
Variants
Works for some users, denied for others
Group assignment gap. Compare a working user's groups with the failing user's.
"User not provisioned" variant
SCIM provisioning failed or never ran. Check the provisioning logs in the IdP.
Why it happens
SSO has two gates: authentication (who are you) and authorization (may you enter). The IdP owns the first, the app owns the second. "Access denied" after SSO means gate one passed and gate two rejected.
Edge cases
- Just-in-time provisioning apps: the first login creates the account; a failed first attempt can leave a half-created user.
- License reclaim: deprovisioned users keep IdP assignment but lose the seat; clean up both.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_3u9X0cffI7EN-fz5VNkI4Q
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.