feat(oidc): add Microsoft Identity OpenID Connect provider#202
feat(oidc): add Microsoft Identity OpenID Connect provider#202halvaradop wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds Microsoft Identity OpenID provider support and a new documentation page covering setup, provider configuration, sign-in paths, and session retrieval. Several package manifests also have end-of-file closing-brace adjustments. ChangesMicrosoft Identity support
Package manifest EOF adjustments
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/src/content/docs/`(core)/oauth/microsoft-identity.mdx:
- Around line 91-96: The Microsoft Identity customization example is using
GitHub-only scopes, so update the scope value in the microsoftIdentity authorize
params example to standard OpenID Connect scopes and, if needed, mention
Microsoft Graph delegated permissions for extra API access. Make sure the
example under microsoftIdentity uses valid Entra ID scopes rather than read:user
and user:email so the customization snippet matches the intended provider
behavior.
In `@packages/core/src/oauth/microsoft-identity.ts`:
- Around line 34-52: The Microsoft Identity issuer still contains an unresolved
:tenantId placeholder, so the provider builds an invalid discovery URL. Update
the microsoftIdentity factory to accept a tenantId option (defaulting to common)
and construct the issuer dynamically instead of relying on
MICROSOFT_IDENTITY_ISSUER as a fixed string. Make sure the returned
OpenIDProvider uses the computed issuer in microsoftIdentity, and update the
Microsoft Identity docs to describe the required tenant configuration and valid
tenant values.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: dc6516c6-d11e-456d-a226-71a1b7f36a82
📒 Files selected for processing (8)
docs/src/content/docs/(core)/oauth/microsoft-identity.mdxpackages/core/src/oauth/microsoft-identity.tspackages/elysia/package.jsonpackages/express/package.jsonpackages/hono/package.jsonpackages/next/package.jsonpackages/react-router/package.jsonpackages/react/package.json
| microsoftIdentity({ | ||
| authorize: { | ||
| params: { | ||
| // Override default scopes | ||
| scope: "read:user user:email", | ||
| }, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major
🧩 Analysis chain
🌐 Web query:
Microsoft Entra ID OIDC scopes openid profile email read:user user:email
💡 Result:
In Microsoft Entra ID (Microsoft identity platform), OpenID Connect (OIDC) scopes are used to request specific information about the authenticated user and to authorize the application [1][2]. The scopes you mentioned are categorized as follows: 1. OIDC Standard Scopes (Supported): - openid: This is a required scope for OpenID Connect flows [1][3]. It instructs the identity platform to return an ID token and translates to the "Sign you in" permission in the consent user interface [1][3][4]. - profile: This scope provides access to a broad range of user information, such as given name, surname, preferred username, and object ID [1]. It is required for accessing claims like given_name, family_name, and preferred_username [5]. - email: This scope enables the application to receive the user's email address claim [6]. For managed users within a tenant, requesting this scope is the standard way to ensure the email claim is included [5]. 2. Other Scopes: - read:user and user:email: These are not standard OIDC scopes supported by the Microsoft identity platform [1][4]. While you may encounter these in other identity providers (such as GitHub), in the Microsoft ecosystem, you should use the official scopes listed above (openid, profile, email) [1][4] or Microsoft Graph permissions (such as User.Read) to access specific user data [7][6][8]. Key Implementation Notes: - UserInfo Endpoint: The openid, profile, and email scopes are used to authorize calls to the Microsoft Graph-hosted UserInfo endpoint, which returns claims about the authenticated user [3][6]. - Automatic Scopes: Be aware that Microsoft Entra ID may automatically include additional scopes, such as offline_access (for refresh tokens) or User.Read, in your authorization requests to ensure proper application functionality [9][2][8]. - Authorization vs. Identity: If your application needs to query data from Microsoft Graph APIs beyond basic identity information, you must request specific Microsoft Graph delegated permissions (e.g., User.Read, Mail.Read) rather than relying solely on OIDC scopes [7][8].
Citations:
- 1: https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc
- 2: https://learn.microsoft.com/en-us/entra/identity-platform/consent-types-developer
- 3: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc
- 4: https://github.com/MicrosoftDocs/entra-docs/blob/main/docs/identity-platform/scopes-oidc.md
- 5: https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference
- 6: https://learn.microsoft.com/en-us/entra/identity-platform/userinfo
- 7: https://learn.microsoft.com/en-us/entra/architecture/authorize-applications-resources-workloads
- 8: https://stackoverflow.com/questions/65241844/whats-the-difference-between-user-read-vs-openid-profile-email-permissions-in-a
- 9: https://learn.microsoft.com/en-us/answers/questions/2282018/discrepancy-in-consent-scopes-between-microsoft-en
Correct Microsoft Identity scopes in the customization example.
The scope values read:user user:email are specific to GitHub’s API and are invalid for Microsoft Identity (Entra ID). Using them will cause an invalid_scope error during authorization.
Replace the scope string with standard OpenID Connect scopes (openid profile email) and add Microsoft Graph delegated permissions (e.g., User.Read) if specific Graph data access is required.
Proposed correction
authorize: {
params: {
// Override default scopes
- scope: "read:user user:email",
+ scope: "openid profile email",
},
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| microsoftIdentity({ | |
| authorize: { | |
| params: { | |
| // Override default scopes | |
| scope: "read:user user:email", | |
| }, | |
| microsoftIdentity({ | |
| authorize: { | |
| params: { | |
| // Override default scopes | |
| scope: "openid profile email", | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/src/content/docs/`(core)/oauth/microsoft-identity.mdx around lines 91 -
96, The Microsoft Identity customization example is using GitHub-only scopes, so
update the scope value in the microsoftIdentity authorize params example to
standard OpenID Connect scopes and, if needed, mention Microsoft Graph delegated
permissions for extra API access. Make sure the example under microsoftIdentity
uses valid Entra ID scopes rather than read:user and user:email so the
customization snippet matches the intended provider behavior.
| export const MICROSOFT_IDENTITY_ISSUER = "https://login.microsoftonline.com/:tenantId/v2.0" | ||
|
|
||
| /** | ||
| * Microsoft Identity Platform OpenID Connect Provider | ||
| * | ||
| * @see [Microsoft Identity Platform - OpenID Connect](https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc) | ||
| * @see [Microsoft Identity Platform - OpenID Connect Metadata Document](https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) | ||
| * @see [Microsoft Identity Platform - OpenID Connect ID Token Claims](https://learn.microsoft.com/en-us/entra/identity-platform/id-tokens) | ||
| * @see [Microsoft Identity Platform - OpenID Connect Scopes](https://learn.microsoft.com/en-us/entra/identity-platform/scopes-oidc) | ||
| * @see [Microsoft Identity Platform - UserInfo Endpoint](https://learn.microsoft.com/en-us/entra/identity-platform/userinfo) | ||
| * @see [Microsoft Identity Platform - ID Token Claims Reference](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference) | ||
| */ | ||
| export const microsoftIdentity = <DefaultUser extends User = User>( | ||
| options?: Partial<OpenIDProvider<MicrosoftIdentityProfile, DefaultUser, typeof MICROSOFT_IDENTITY_ISSUER>> | ||
| ): OpenIDProvider<MicrosoftIdentityProfile, DefaultUser, typeof MICROSOFT_IDENTITY_ISSUER> => { | ||
| return { | ||
| id: "microsoft-identity", | ||
| name: "Microsoft Identity", | ||
| issuer: MICROSOFT_IDENTITY_ISSUER, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check whether Microsoft Identity issuer placeholders are interpolated anywhere.
rg -n --fixed-strings ':tenantId' .
rg -n 'MICROSOFT_IDENTITY_ISSUER|microsoft-identity|tenantId|issuer.*replace' .Repository: aura-stack-ts/auth
Length of output: 1805
Fix the unresolved :tenantId placeholder in the Microsoft Identity issuer.
The MICROSOFT_IDENTITY_ISSUER constant contains a literal :tenantId string that is never interpolated or replaced by the core framework. Microsoft's v2.0 OpenID Connect endpoints strictly require a valid tenant segment (e.g., common, organizations, consumers, or a specific GUID) to resolve the discovery document. Verification confirms no codebase logic performs string replacement on this placeholder, meaning the provider will attempt to fetch metadata from an invalid path (.../:tenantId/v2.0), causing authentication failure.
Update the microsoftIdentity factory to accept a tenantId parameter (defaulting to "common") and construct the issuer dynamically:
export const microsoftIdentity = <DefaultUser extends User = User>(
options?: { tenantId?: string } & Partial<OpenIDProvider<MicrosoftIdentityProfile, DefaultUser, string>>
): OpenIDProvider<MicrosoftIdentityProfile, DefaultUser, string> => {
const tenant = options?.tenantId ?? "common";
const issuer = `https://login.microsoftonline.com/${tenant}/v2.0`;
return {
id: "microsoft-identity",
name: "Microsoft Identity",
issuer,
// ...
};
};Update the documentation in docs/src/content/docs/(core)/oauth/microsoft-identity.mdx to reflect this new configuration requirement.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/core/src/oauth/microsoft-identity.ts` around lines 34 - 52, The
Microsoft Identity issuer still contains an unresolved :tenantId placeholder, so
the provider builds an invalid discovery URL. Update the microsoftIdentity
factory to accept a tenantId option (defaulting to common) and construct the
issuer dynamically instead of relying on MICROSOFT_IDENTITY_ISSUER as a fixed
string. Make sure the returned OpenIDProvider uses the computed issuer in
microsoftIdentity, and update the Microsoft Identity docs to describe the
required tenant configuration and valid tenant values.
Description
This pull request adds support for the Microsoft Identity OAuth 2.0 / OpenID Connect (OIDC) provider to the list of authentication providers available in Aura Auth.
Usage
Note
This PR will remain in draft until the Microsoft Identity OAuth 2.0 / OIDC provider has been fully validated with Aura Auth.
The implementation successfully passes the basic authentication flows and core use cases, but it has not yet been comprehensively tested. Additional validation is required to ensure provider-specific behaviors work correctly and to identify any edge cases before this feature is considered production-ready.
Summary by CodeRabbit
New Features
Documentation
Chores