feat(oidc): add Azure AD B2C OpenID Connect Provider#201
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds a new Azure AD B2C OAuth provider factory and a documentation page covering app registration, environment variables, auth instance setup, provider customization, sign-in examples, session retrieval, and reference links. ChangesAzure AD B2C Integration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 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
🧹 Nitpick comments (1)
docs/src/content/docs/(core)/oauth/azure-ad-b2c.mdx (1)
177-181: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueServer-side session retrieval example lacks request context clarity.
The comment states "You must pass the native Web Request object or Headers" but the example only shows
api.getSession(request)without clarifying whererequestoriginates. In Next.js App Router this would beheaders()or the incomingRequest; in other frameworks it differs. Consider adding a brief framework-specific hint or showing the import source ofrequest.🤖 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/azure-ad-b2c.mdx around lines 177 - 181, The session retrieval example is missing the source of the native request context, so update the docs snippet around api.getSession(request) to clearly show where request comes from or mention the framework-specific alternative such as the incoming Request or headers() in App Router. Keep the example aligned with the existing api.getSession and session.user usage, but add a brief hint that makes the required request/headers input unambiguous.
🤖 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/azure-ad-b2c.mdx:
- Around line 85-103: The scope override example in azureADB2C is using
GitHub-specific scopes, so update the example under createAuth/azureADB2C to use
Azure AD B2C/OpenID Connect scopes instead. Replace the authorize.params.scope
value with appropriate B2C scopes such as openid, profile, email, or a
tenant-registered custom scope, and keep the snippet aligned with the auth.ts
example shown in the doc.
- Around line 36-44: The Azure AD B2C setup docs are missing required tenant and
policy environment variables, so the endpoint templates in azure-ad-b2c.ts
cannot be resolved. Update the environment example in the OAuth Azure AD B2C
docs to include the missing AURA_AUTH_AZURE_AD_B2C_TENANT and
AURA_AUTH_AZURE_AD_B2C_POLICY variables alongside CLIENT_ID and CLIENT_SECRET.
Make sure the section clearly matches the placeholders used by the AzureAdB2C
provider factory so users can configure the authorization, token, and metadata
URLs correctly.
---
Nitpick comments:
In `@docs/src/content/docs/`(core)/oauth/azure-ad-b2c.mdx:
- Around line 177-181: The session retrieval example is missing the source of
the native request context, so update the docs snippet around
api.getSession(request) to clearly show where request comes from or mention the
framework-specific alternative such as the incoming Request or headers() in App
Router. Keep the example aligned with the existing api.getSession and
session.user usage, but add a brief hint that makes the required request/headers
input unambiguous.
🪄 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: 1633bc96-8e6f-47c9-aca6-37236d060c00
📒 Files selected for processing (2)
docs/src/content/docs/(core)/oauth/azure-ad-b2c.mdxpackages/core/src/oauth/azure-ad-b2c.ts
Description
This pull request adds support for the Azure Active Directory B2C 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 Azure AD B2C 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.
Notes
During the implementation of this provider, several inconsistencies and gaps were identified in the Azure AD B2C documentation.
The OAuth 2.0 documentation describes the authorization and token endpoints:
However, it does not mention a
/userinfoendpoint or any alternative endpoint for retrieving authenticated user profile information.Azure AD B2C also supports OpenID Connect, which introduces policy-specific endpoints:
Despite advertising OpenID Connect support, the discovery document:
does not expose a
userinfo_endpoint.Although the UserInfo endpoint is optional in both OAuth 2.0 and OpenID Connect, the documentation does not explain how applications are expected to retrieve user profile information or whether the issued access token can be used with Microsoft APIs (for example,
GET /mein Microsoft Graph). Because of this uncertainty, the provider will remain in draft status until these behaviors are fully understood and validated.During this investigation, it also became clear that Microsoft implements OAuth 2.0 and OpenID Connect with protocol-specific differences that require additional handling within the provider implementation.
Finally, this work led to the discovery of the Microsoft Identity Platform, which appears to be a better foundation for implementing future Microsoft authentication providers.
For reference:
https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc