Social Login
App Auth supports Google and GitHub as social sign-in providers. When configured, buttons for each provider appear on the hosted login page alongside the magic-link option. End-user identities from social sign-in land in your _mdb_auth schema alongside magic-link users: same schema, same session model, same erasure semantics.
You supply your own OAuth app credentials from each provider. The platform stores the client_secret in the platform secret store and never returns it in any API response.
Register an OAuth app at the provider
Before configuring a provider, create an OAuth application at the provider's developer console.
Google: Go to Google Cloud Console and create an OAuth 2.0 client. Set the application type to "Web application". Add the following to Authorized redirect URIs:
https://<your-issuer-host>/callback/google
GitHub: Go to GitHub Developer Settings and create a new OAuth App. Set the Authorization callback URL to:
https://<your-issuer-host>/callback/github
Replace <your-issuer-host> with your app's issuer host, for example auth-1a2b3c4d.foundrydb.com. You can find the issuer host in the fallback_domain field of GET /app-services/$APP_ID/auth.
Add a provider
# Add Google
curl -u "$USER:$PASS" -X PUT \
https://api.foundrydb.com/app-services/$APP_ID/auth/providers/google \
-H "Content-Type: application/json" \
-d '{
"client_id": "1234567890-abcdef.apps.googleusercontent.com",
"client_secret": "GOCSPX-...",
"display_name": "Sign in with Google"
}'
# Add GitHub
curl -u "$USER:$PASS" -X PUT \
https://api.foundrydb.com/app-services/$APP_ID/auth/providers/github \
-H "Content-Type: application/json" \
-d '{
"client_id": "Ov23li...",
"client_secret": "...",
"display_name": "Sign in with GitHub"
}'
The display_name field is optional. When omitted, the login button label defaults to the provider name ("Google" or "GitHub").
The response returns the full list of configured providers after the operation. Secrets are never included:
{
"providers": [
{
"provider": "google",
"client_id": "1234567890-abcdef.apps.googleusercontent.com",
"display_name": "Sign in with Google"
}
]
}
When the auth configuration is Active, the issuer redeploys automatically to pick up the new credentials. If the configuration is not yet Active, the change is applied on the next deploy.
Update a provider
Sending a PUT to a provider that is already configured replaces the credentials:
curl -u "$USER:$PASS" -X PUT \
https://api.foundrydb.com/app-services/$APP_ID/auth/providers/google \
-H "Content-Type: application/json" \
-d '{
"client_id": "new-client-id.apps.googleusercontent.com",
"client_secret": "new-secret"
}'
This is the same endpoint and same semantics as adding a provider. Rotate provider credentials here when you cycle secrets at the OAuth provider.
List configured providers
curl -u "$USER:$PASS" \
https://api.foundrydb.com/app-services/$APP_ID/auth/providers
Returns the configured provider list with client IDs and display names. Secrets are never returned.
Remove a provider
curl -u "$USER:$PASS" -X DELETE \
https://api.foundrydb.com/app-services/$APP_ID/auth/providers/google
The response returns the remaining configured providers. When the auth configuration is Active, the issuer redeploys automatically to remove the provider's button from the login page.
How social identities are stored
When a user signs in with Google or GitHub for the first time, the platform creates:
- A row in
_mdb_auth.userswith a UUID subject identifier - A row in
_mdb_auth.identitieslinking the user to the provider and the provider's user ID
If a user signs in with a social provider using the same email address as an existing magic-link user, the platform links the identity to the existing user record. The same user can have multiple identities across different sign-in methods.
The sub claim in the JWT is always the _mdb_auth.users.id UUID, regardless of the sign-in method. Your application should use this UUID as the stable identifier for your users.
Next steps
- Integrate from Your App — wire the OIDC issuer to your application
- Enable Auth — session revocation and GDPR erasure