Skip to content

docs: document upstream MFA carry-over for OIDC social sign-in#2507

Open
hperl wants to merge 1 commit intomasterfrom
feat/oidc-upstream-mfa-carryover
Open

docs: document upstream MFA carry-over for OIDC social sign-in#2507
hperl wants to merge 1 commit intomasterfrom
feat/oidc-upstream-mfa-carryover

Conversation

@hperl
Copy link
Copy Markdown
Collaborator

@hperl hperl commented Apr 13, 2026

Summary

Documents the new upstream OIDC acr / amr carry-over feature shipped in ory-corp/cloud#11499.

When a user signs in through a social sign-in provider that already enforces MFA, Ory can now trust the upstream factor instead of asking the user to complete a second factor again. This PR adds:

  • A new page Upstream MFA carry-over (docs/kratos/social-signin/93_upstream-mfa.mdx) covering:
    • How Ory reads the upstream acr / amr claims and decides the resulting session AAL.
    • A provider support matrix (Generic OIDC, Auth0, Okta, Keycloak, Microsoft Entra v1, Ping Identity, Google, Apple, and others).
    • Console and CLI configuration examples for aal2_acr_values and aal2_amr_values.
    • How to ask the upstream provider for a specific acr value via acr_values or requested_claims.
    • A sample /sessions/whoami payload showing the new upstream_acr / upstream_amr audit fields.
    • Troubleshooting tips for empty upstream claims and accidental AAL2 elevation.
  • A short cross-link section on the Dynamic Multi-Factor Authentication page so customers enforcing AAL2 discover the option.
  • A sidebar entry for the new page under OpenID Connect SSO.

Test plan

  • npx prettier --check passes for changed files
  • Local docusaurus build (npm run build) — please verify in CI

Related

  • ory-corp/cloud#11499 — implementation PR
  • ory-corp/cloud#11494 — issue

🤖 Generated with Claude Code

Adds a new page describing how Ory carries over upstream OIDC `acr` and
`amr` claims into the resulting Ory session. Operators can configure
per-provider `aal2_acr_values` and `aal2_amr_values` allowlists to mark
sessions as AAL2 when the upstream identity provider has already
performed multi-factor authentication.

The new page covers:

- How Ory reads the upstream `acr` / `amr` claims and decides the
  session AAL.
- A provider support matrix (Generic OIDC, Auth0, Okta, Keycloak,
  Microsoft Entra v1, Ping Identity, Google, Apple, and others).
- Console and CLI configuration examples.
- How to ask the upstream provider for a specific `acr` value via
  `acr_values` or `requested_claims`.
- Sample `/sessions/whoami` payload showing the new `upstream_acr` /
  `upstream_amr` audit fields.
- Troubleshooting tips for empty upstream claims and accidental AAL2
  elevation.

The Dynamic MFA / step-up authentication doc gains a short section that
links to the new page so customers enforcing AAL2 discover the option.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
Member

@vinckr vinckr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small formatting changes


## Troubleshooting

**The session is still AAL1 after a successful login.** Check that the upstream provider actually emits the claim. You can inspect
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**The session is still AAL1 after a successful login.** Check that the upstream provider actually emits the claim. You can inspect
The session is still AAL1 after a successful login: Check that the upstream provider actually emits the claim. You can inspect

`std.extVar('claims').raw_claims.amr`. If the provider doesn't surface the claim, request it explicitly through `acr_values` or
`requested_claims`.

**The `upstream_acr` field is empty even though the upstream sent it.** Make sure your provider config has
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**The `upstream_acr` field is empty even though the upstream sent it.** Make sure your provider config has
The `upstream_acr` field is empty even though the upstream sent it: Make sure your provider config has

`claims_source: id_token` (the default) or, if you set `claims_source: userinfo`, that the userinfo endpoint also returns the
`acr` claim. Some providers only include `acr`/`amr` in the ID token.

**The session is AAL2 but the user never completed MFA.** Audit the configured allowlists carefully. An `acr` value such as `0` or
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**The session is AAL2 but the user never completed MFA.** Audit the configured allowlists carefully. An `acr` value such as `0` or
The session is AAL2 but the user never completed MFA: Audit the configured allowlists carefully. An `acr` value such as `0` or

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

upstream Issue is caused by an upstream dependency.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants