Auth Service supports federated login through Google (OpenID Connect) and GitHub (OAuth2). When a user authenticates through either provider, the service resolves the verified email from the provider’s identity token and either links it to an existing account or creates a new one — no separate registration step is needed. Federated identities are linked permanently to the internal account, so the same user can later log in with credentials or through any provider they have ever used.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/ricardomb-tech/auth-service/llms.txt
Use this file to discover all available pages before exploring further.
Google OAuth2
Google is a full OpenID Connect (OIDC) provider. Auth Service reads thesub, email, and email_verified claims directly from the OIDC ID token — no secondary API call is needed.
Create an OAuth2 client in Google Cloud Console
- Open the Google Cloud Console and select (or create) a project.
- Navigate to APIs & Services → Credentials.
- Click Create Credentials → OAuth client ID.
- Choose Web application as the application type.
- Give the client a name (e.g.
auth-service).
Set the authorized redirect URI
Under Authorized redirect URIs, add the callback URL for Auth Service:For local development this is:This URI is handled internally by Spring Security — you do not need to write a controller for it. Do not add any other paths or query parameters.
Copy the credentials to your environment
After saving, Google displays the Client ID and Client Secret. Set them as environment variables:
Verify the configured scopes
The following scopes are requested automatically by Auth Service. No additional configuration is required on the Google side for these standard scopes:
| Scope | Purpose |
|---|---|
openid | Signals OIDC flow; enables the ID token with sub and email_verified |
email | Includes the user’s email address in the token |
profile | Includes basic profile information (name, picture) |
GitHub OAuth2
GitHub is not an OIDC provider — it does not issue ID tokens and itsGET /user endpoint does not expose whether an email is verified. Auth Service handles this with a custom GitHubOAuth2UserService that calls GET /user/emails after the base user is loaded and injects the primary verified email as synthetic email and email_verified attributes. The success handler then reads these attributes using the same code path as Google, so no provider-specific branching is needed downstream.
Create an OAuth App in GitHub
- Open GitHub Settings → Developer settings → OAuth Apps.
- Click New OAuth App.
- Fill in Application name, Homepage URL, and the callback URL (next step).
Set the callback URL
In the Authorization callback URL field, enter the Spring Security callback path for GitHub:For local development:GitHub allows only a single callback URL per OAuth App. If you need separate URLs for development and production, create two separate OAuth Apps.
Copy the credentials to your environment
After registering the app, generate a Client Secret on the app’s settings page. Set both values:
Verify the required scopes
Auth Service requests two scopes from GitHub:
| Scope | Purpose |
|---|---|
read:user | Reads the public profile from GET /user (display name, avatar, etc.) |
user:email | Grants access to GET /user/emails — required to retrieve the primary verified email |
The
user:email scope is mandatory. GitHub hides email addresses from GET /user by default and does not expose a verified status there. Without user:email, GitHubOAuth2UserService cannot call GET /user/emails to determine the primary verified email address, and the login will fail.Redirect URI Configuration
After OAuth2 authentication succeeds or fails, Auth Service redirects the user’s browser to a frontend URL. These URLs are configurable and validated at startup byOAuth2RedirectProperties.
Frontend URL the browser is redirected to after a successful OAuth2 login. A short-lived, one-time
code parameter is appended automatically by OAuth2AuthenticationSuccessHandler.Example: http://localhost:3000/oauth2/successThe resulting redirect will look like:Frontend URL the browser is redirected to when OAuth2 login fails — for example, because the user denied consent, the provider returned an error, or the email returned by the provider was not verified.Example:
http://localhost:3000/oauth2/failureWhy a one-time exchange code instead of the JWT in the URL?After a successful OAuth2 login,
OAuth2AuthenticationSuccessHandler issues a short-lived, single-use exchange code and redirects the browser to OAUTH2_SUCCESS_REDIRECT_URI?code=<code>. The frontend must then call POST /auth/oauth2/exchange with that code to receive the actual Access Token and Refresh Token pair.This indirection is intentional: placing JWTs directly in redirect URLs would expose them in the browser’s history, server and proxy access logs, and via the HTTP Referer header if the frontend page loads any external resources. The exchange code is meaningless on its own — it can only be redeemed once, and only by a request that arrives before it expires.OAuth2 Flow Overview
application.properties Reference
The full OAuth2 provider mapping in application.properties for reference: