An IdP cleanup changes claim names and Grafana users later authenticate successfully but lose admin or editor access unexpectedly.
A Grafana OAuth login works and role sync stays wrong because the identity provider renamed the group claim while Grafana still maps authorization from the old claim key
Users can authenticate, yet they land with the wrong role because the expected group claim is no longer in the token under the old name.
Scenario
What to check first
- Identify the primary failure signal in the IAM scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Inspect token claim names and Grafana role mapping expressions before resetting user accounts.
Questions worth viewing together
Community-field security problem inspired by Grafana community threads where OAuth role mapping broke after group claim names changed. Successful login does not prove authorization claims are still named the way the app expects.
Teams often blame stale Grafana sessions when the IdP changed the group claim key.
SSO changes should validate both authentication and authorization claim contracts.
Similar cases seen in the field