feat(oidc): add Hugging Face OpenID Connect Provider#198
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughAdds a Hugging Face OAuth/OpenID provider and a documentation page covering app setup, configuration, sign-in flows, session retrieval, and related references. ChangesHugging Face OAuth provider and docs
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/core/src/oauth/huggingface.ts (1)
56-62: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueProfile mapping drops available claims.
HuggingFaceProfileexposesemail_verified(andpreferred_username), but the mapping only forwardssub/name/email/image. If the upstreamUser/Aura profile shape supportsemail_verified/nickname(as the preset inpackages/core/test/presets.tssuggests), consider mapping them through. Theas DefaultUsercast also suppresses any field-shape mismatch.🤖 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/huggingface.ts` around lines 56 - 62, The Hugging Face profile mapper in the `profile` callback is dropping supported claims and the `as DefaultUser` cast is hiding shape mismatches. Update the mapping in `packages/core/src/oauth/huggingface.ts` to forward the additional available fields such as `email_verified` and `preferred_username`/`nickname` when the target user shape supports them, and remove the broad cast so the `HuggingFaceProfile` to user mapping is type-checked against the actual interface.
🤖 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/huggingface.mdx:
- Line 19: The Hugging Face OAuth setup instructions reference the wrong
callback provider path, so update the Redirect URL in the documentation to use
the Hugging Face callback route instead of the GitHub one. Fix the text in the
HuggingFace docs content by replacing the provider segment in the redirect URL
with the Hugging Face provider id so it matches the route used by the OAuth
flow.
- Line 156: The server-side sign-in example in the Hugging Face docs uses the
wrong provider identifier; update the api.signIn call in the Hugging Face page
to use "huggingface" instead of "github". Keep the fix localized to the sign-in
example so it matches the documented provider and the surrounding HuggingFace
OAuth content.
- Line 100: The OAuth example in the HuggingFace docs is using GitHub-only
scopes, so update the scope value in the Hugging Face configuration example to
use Hugging Face/OIDC scopes instead. Adjust the example near the OAuth settings
so it references valid scopes like those used by Hugging Face, and make sure the
surrounding docs text matches the provider-specific behavior to avoid misleading
users.
---
Nitpick comments:
In `@packages/core/src/oauth/huggingface.ts`:
- Around line 56-62: The Hugging Face profile mapper in the `profile` callback
is dropping supported claims and the `as DefaultUser` cast is hiding shape
mismatches. Update the mapping in `packages/core/src/oauth/huggingface.ts` to
forward the additional available fields such as `email_verified` and
`preferred_username`/`nickname` when the target user shape supports them, and
remove the broad cast so the `HuggingFaceProfile` to user mapping is
type-checked against the actual interface.
🪄 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: fb59048d-489e-4568-8e1c-dc2ddcee2e5c
📒 Files selected for processing (2)
docs/src/content/docs/(core)/oauth/huggingface.mdxpackages/core/src/oauth/huggingface.ts
| 1. Navigate to your Hugging Face profile and go to **Settings > Connected Apps > Developer Applications**. | ||
| 2. Click **Create App**. | ||
| 3. Fill in the "Application name" and "Homepage URL". | ||
| 4. Set the **Redirect URL** to `http://localhost:3000/auth/callback/github`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Redirect URL uses the wrong provider path (github).
The callback path must match the Hugging Face provider id, otherwise the configured redirect URI won't match the route and the OAuth flow will fail.
🔧 Proposed fix
-4. Set the **Redirect URL** to `http://localhost:3000/auth/callback/github`.
+4. Set the **Redirect URL** to `http://localhost:3000/auth/callback/huggingface`.📝 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.
| 4. Set the **Redirect URL** to `http://localhost:3000/auth/callback/github`. | |
| 4. Set the **Redirect URL** to `http://localhost:3000/auth/callback/huggingface`. |
🤖 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/huggingface.mdx at line 19, The Hugging
Face OAuth setup instructions reference the wrong callback provider path, so
update the Redirect URL in the documentation to use the Hugging Face callback
route instead of the GitHub one. Fix the text in the HuggingFace docs content by
replacing the provider segment in the redirect URL with the Hugging Face
provider id so it matches the route used by the OAuth flow.
| export const auth = createAuth({ | ||
| oauth: [ | ||
| huggingface({ | ||
| scope: "read:user user:email", |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor
🧩 Analysis chain
🌐 Web query:
Hugging Face OAuth supported scopes openid profile email read-repos
💡 Result:
Hugging Face OAuth supports the scopes you mentioned (openid, profile, email, read-repos), along with several others [1][2]. The scopes you listed function as follows: - openid: Retrieves the ID token in addition to the access token [1][3]. - profile: Retrieves the user's profile information, such as their username and avatar [1][3]. - email: Retrieves the user's email address [1][3]. - read-repos: Grants read access to the user's personal repositories [1][3]. Other currently supported scopes include [1][3]: - gated-repos: Grants read access to public gated repositories you have been granted access to (distinct from read-repos, which covers private repositories) [1][3]. - write-repos: Grants read and write access to the user's personal repositories [1][3]. - manage-repos: Grants full access to personal repositories, including the ability to create and delete them [1][3]. - contribute-repos: Allows the application to create repositories and access those it has created [1][3]. - read-collections / write-collections: Provides access to manage personal collections [1][3]. - read-billing: Checks if the user has a payment method configured [1][3]. - inference-api: Enables making inference requests on behalf of the user [1][3]. - write-discussions: Allows interacting with discussions, including opening issues or pull requests [1][3]. - jobs and webhooks: Provides management capabilities for jobs and webhooks, respectively [1][3]. By default, issued tokens inherit the scopes configured for the OAuth app, but you can request specific scopes by using the scope parameter during the authorization request [1][3]. For applications using Hugging Face Spaces, openid and profile are typically included by default, while others can be added via the Space's metadata [4][5]. Detailed metadata for all supported scopes is available via the OpenID configuration endpoint at https://huggingface.co/.well-known/openid-configuration [3].
Citations:
- 1: https://huggingface.co/docs/hub/oauth
- 2: https://huggingface.co/docs/hub/main/en/oauth
- 3: https://github.com/huggingface/hub-docs/blob/main/docs/hub/oauth.md
- 4: https://huggingface.co/docs/hub/spaces-oauth
- 5: https://huggingface.co/docs/hub/main/en/spaces-oauth
Scopes are GitHub-style, not Hugging Face.
read:user and user:email are GitHub OAuth scopes. Hugging Face supports OIDC scopes like openid, profile, email, and read-repos. Update the example to prevent misleading users.
🔧 Proposed fix
- scope: "read:user user:email",
+ scope: "openid profile email read-repos",📝 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.
| scope: "read:user user:email", | |
| scope: "openid profile email read-repos", |
🤖 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/huggingface.mdx at line 100, The OAuth
example in the HuggingFace docs is using GitHub-only scopes, so update the scope
value in the Hugging Face configuration example to use Hugging Face/OIDC scopes
instead. Adjust the example near the OAuth settings so it references valid
scopes like those used by Hugging Face, and make sure the surrounding docs text
matches the provider-specific behavior to avoid misleading users.
| import { api } from "./auth" | ||
|
|
||
| export const serverSignIn = async () => { | ||
| const response = await api.signIn("github", { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Server-side sign-in uses "github" instead of "huggingface".
This page documents the Hugging Face provider; the server-side example calls api.signIn("github", ...).
🔧 Proposed fix
- const response = await api.signIn("github", {
+ const response = await api.signIn("huggingface", {📝 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.
| const response = await api.signIn("github", { | |
| const response = await api.signIn("huggingface", { |
🤖 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/huggingface.mdx at line 156, The
server-side sign-in example in the Hugging Face docs uses the wrong provider
identifier; update the api.signIn call in the Hugging Face page to use
"huggingface" instead of "github". Keep the fix localized to the sign-in example
so it matches the documented provider and the surrounding HuggingFace OAuth
content.
halvaradop
added
the
oauth
1 participant
Description
This pull request adds support for the Hugging Face OpenID Connect (OIDC) provider to the list of authentication providers available in Aura Auth.
This is the second OIDC provider supported by Aura Auth. Additional OAuth/OIDC providers will be added in future releases to provide broader coverage of commonly used identity providers for web applications.
Usage
Note
This PR will remain in draft status until the Hugging Face OIDC provider has been fully validated with Aura Auth.
While the implementation passes the basic authentication flows and core use cases, it has not yet been comprehensively tested. Additional verification is required to ensure all provider-specific behaviors work as expected and to identify any edge cases before the feature is considered production-ready.