Naver redirect URL for production
For production, the Naver redirect URL should be set to the URL of your application. If the base path of the auth routes is changed, the redirect URL must be updated accordingly.
social & oauth providers
21 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Naver redirect URL for local development
For local development, the Naver redirect URL must be set to http://localhost:3000/api/auth/callback/naver.
Naver credentials from Naver Developers
To use Naver sign in, you need a client ID and client secret. These can be obtained from https://developers.naver.com/.
Configure Naver provider in betterAuth
To configure the Naver provider, import betterAuth and pass the provider configuration to the socialProviders option. The naver object requires clientId and clientSecret properties populated from environment variables.
Sign in with Naver using client
To sign in with Naver, use the authClient.signIn.social() function with provider set to 'naver'. Example: await authClient.signIn.social({ provider: 'naver' })
Figma provider configuration in Better Auth
To configure the Figma provider, import it and pass it to the `socialProviders` option of the auth instance. The configuration requires `clientId` and `clientSecret` properties. Example: betterAuth({ socialProviders: { figma: { clientId: process.env.FIGMA_CLIENT_ID, clientSecret: process.env.FIGMA_CLIENT_SECRET } } })
Figma developer app credentials
To get Figma OAuth credentials, sign in to your Figma account, navigate to the Developer Apps page, click "Create new app", fill out the app details, configure the redirect URI, and note the Client ID and Client Secret.
Figma OAuth default scope
The default scope for Figma OAuth is `current_user:read`. Additional scopes like `file_content:read` are available and documented in the Figma OAuth scopes documentation.
Figma redirect URI configuration
The redirect URI for Figma authentication should be set to match the application's callback URL, for example `https://yourdomain.com/api/auth/callback/figma`. If the base path of the auth routes changes, the redirect URI must be updated accordingly.
GitHub OAuth refresh tokens
GitHub does not issue refresh tokens for OAuth apps. GitHub issues access tokens that remain valid indefinitely unless the user revokes them, the app revokes them, or they go unused for a year. No refresh token is needed because access tokens do not expire on a short interval.
GitHub user:email scope requirement
The user:email scope must be included in the GitHub app configuration to use GitHub sign in.
Configure GitHub provider in Better Auth
Import the GitHub provider and pass it to the socialProviders option of the auth instance. The provider configuration requires clientId and clientSecret as strings passed from environment variables.
GitHub provider configuration example
import { betterAuth } from "better-auth" export const auth = betterAuth({ socialProviders: { github: { clientId: process.env.GITHUB_CLIENT_ID as string, clientSecret: process.env.GITHUB_CLIENT_SECRET as string, }, }, }) This example shows how to configure the GitHub OAuth provider with credentials from environment variables.
GitHub app email permission setup
For GitHub apps (not OAuth apps), you must enable email reading permissions. After creating the app, go to Permissions and Events > Account Permissions > Email Addresses and select "Read-Only", then save changes.
email_not_found error causes for GitHub
The email_not_found error occurs when either (a) you created a GitHub App and did not grant the "Email addresses: Read-only" permission, or (b) the user has set their primary email to private, in which case the GET /user endpoint returns email: null. The user's private email addresses are available via the /user/emails endpoint.
Get GitHub credentials
GitHub client ID and client secret can be obtained from the GitHub Developer Portal at https://github.com/settings/developers.
GitLab OAuth redirect URL for local development
For local development, set the GitLab OAuth redirect URL to http://localhost:3000/api/auth/callback/gitlab. For production, set it to the URL of your application. If you change the base path of the auth routes, update the redirect URL accordingly.
GitLab provider configuration options
GitLab provider supports the following configuration options: clientId (required, string) - the GitLab application's Client ID; clientSecret (required, string) - the GitLab application's Client Secret; issuer (optional, string) - the URL of your GitLab instance, defaults to "https://gitlab.com" for GitLab.com, use this option for self-hosted GitLab servers.
GitLab provider configuration example
Example configuration of GitLab provider in auth.ts: ```ts import { betterAuth } from "better-auth" export const auth = betterAuth({ socialProviders: { gitlab: { clientId: process.env.GITLAB_CLIENT_ID as string, clientSecret: process.env.GITLAB_CLIENT_SECRET as string, issuer: process.env.GITLAB_ISSUER as string, }, }, }) ```
GitLab provider configuration with self-hosted instance
Example configuration for self-hosted GitLab: ```ts export const auth = betterAuth({ socialProviders: { gitlab: { clientId: process.env.GITLAB_CLIENT_ID as string, clientSecret: process.env.GITLAB_CLIENT_SECRET as string, issuer: "https://gitlab.company.com", }, }, }) ```
GitLab OAuth documentation reference
To get GitLab credentials, refer to the GitLab OAuth documentation at https://docs.gitlab.com/ee/api/oauth2.html.