BE-477: Add Microsoft/Azure AD OIDC SSO provider

[TimDiekmann]

🌟 What is the purpose of this PR?

Add Microsoft/Azure AD as second OIDC provider, building on the Google SSO foundation from BE-476.

🔗 Related links

• BE-477: Set up Microsoft/Azure AD OIDC SSO (internal)
• Stacked on BE-476: Add Google OIDC SSO support via Ory Kratos #8576 (BE-476: Google OIDC SSO)

🔍 What does this change?

• Add Microsoft OIDC provider config in kratos.yml
• Add Jsonnet claims mapper for Microsoft (handles email, preferred_username, upn)
• Add docker-compose env vars for Microsoft client_id, client_secret, tenant_id

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

🛡 What tests cover this?

• Manual testing: Microsoft OIDC login flow on local and staging

❓ How to test this?

Tested and verified on staging with Azure AD accounts.

🎥 Demo

[cursor]

PR Summary

Medium Risk
Adds a new SSO identity provider and claim-mapping logic in Kratos, which can affect authentication, account linking, and email verification behavior if misconfigured. Changes are mostly additive and gated behind the existing OIDC enable flag.

Overview
Adds Microsoft/Azure AD as an additional OIDC SSO provider for Kratos alongside Google.

Updates kratos.yml to register a microsoft provider (including tenant support) and introduces a new oidc.microsoft.jsonnet mapper that derives the user email from multiple possible Microsoft claims and sets verified_addresses based on email_verified when present.

Extends docker-compose.yml to document and wire Microsoft OIDC client_id, client_secret, and tenant_id environment variables into Kratos’ OIDC provider configuration.

^{Written by Cursor Bugbot for commit 6dd8021. This will update automatically on new commits. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hash	Ready	Preview, Comment	Apr 2, 2026 3:50pm

3 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
hashdotdesign	Ignored	Preview	Apr 2, 2026 3:50pm
hashdotdesign-tokens	Ignored	Preview	Apr 2, 2026 3:50pm
petrinaut	Skipped		Apr 2, 2026 3:50pm

[augmentcode]

🤖 Augment PR Summary

Summary: Adds Microsoft/Azure AD (Entra ID) as a second OIDC SSO provider alongside the existing Google OIDC integration.

Changes:

• Introduces a Microsoft-specific claims mapper (`oidc.microsoft.jsonnet`) to derive the user email from available token claims.
• Registers the Microsoft OIDC provider in Kratos config with the new mapper and requested scopes.
• Extends local dev Docker Compose env wiring for Microsoft `client_id`, `client_secret`, and tenant configuration.

Technical Notes: The mapper prioritizes `email`, then `preferred_username`, then `upn` for populating `traits.emails` and verification state.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

[TimDiekmann]

• BE-477: Add Microsoft/Azure AD OIDC SSO provider #8578 👈 (View in Graphite)
• BE-476: Add Google OIDC SSO support via Ory Kratos #8576
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Could not find data on the previous version of this PR; see action logs at https://github.com/hashintel/hash/actions/runs/23908536429

[graphite-app]

Merge activity

• Apr 2, 3:37 PM UTC: Graphite rebased this pull request, because this pull request is set to merge when ready.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Missing requested_claims makes email verification check ineffective

Medium Severity

The Microsoft provider in kratos.yml doesn't include requested_claims for email_verified (unlike the Google provider), so Microsoft will almost never include email_verified in the ID token. This means the email_verified check in oidc.microsoft.jsonnet is effectively dead code — the mapper will always fall into the else branch that unconditionally marks emails as verified. Combined with the preferred_username/upn fallback chain, any value Microsoft returns gets auto-verified without actual verification.

Additional Locations (1)

• apps/hash-external-services/kratos/hooks/oidc.microsoft.jsonnet#L16-L23