Social OAuth
Configure organization-specific social login providers for single sign-on
Enterprise organizations can configure their own OAuth providers to enable branded sign-in. Users sign in with the provider connected to that organization's OAuth application.
Benefits of Organization OAuth
| Benefit | Description |
|---|---|
| Branded Login | Users see your organization's name during sign-in |
| Access Control | Restrict sign-in to your organization's domain |
| Audit Trail | All authentication goes through your OAuth app |
| SSO Integration | Works with existing identity management |
Accessing Social OAuth Settings
- Go to Settings in the sidebar
- Open Enterprise and go to the custom domain and branding area
- View the Social Login Providers management table
OAuth credentials are configured per organization in product settings. Do not treat them as tenant-wide environment variables.
Supported Providers
Google OAuth Setup
- Go to Google Cloud Console
- Create or select a project
- Navigate to APIs & Services > Credentials
- Click Create Credentials > OAuth client ID
- Select Web application
- Add authorized redirect URI:
https://your-z8-domain.com/api/auth/callback/social-org/google - Copy the Client ID and Client Secret
Configuration in Z8
- Click Add Provider > Google
- Enter your Client ID and Client Secret
- Click Save
Microsoft Azure AD Setup
- Go to Azure Portal
- Navigate to Azure Active Directory > App registrations
- Click New registration
- Set redirect URI:
https://your-z8-domain.com/api/auth/callback/social-org/microsoft - Under Certificates & secrets, create a new client secret
- Copy the Application (client) ID and secret value
Configuration in Z8
- Click Add Provider > Microsoft
- Enter your Client ID and Client Secret
- Click Save
GitHub OAuth Setup
- Go to GitHub Developer Settings
- Click OAuth Apps > New OAuth App
- Set Authorization callback URL:
https://your-z8-domain.com/api/auth/callback/social-org/github - Register the application
- Generate a new client secret
- Copy the Client ID and Client Secret
Configuration in Z8
- Click Add Provider > GitHub
- Enter your Client ID and Client Secret
- Click Save
LinkedIn OAuth Setup
- Go to LinkedIn Developers
- Create a new application
- Under Auth, add redirect URL:
https://your-z8-domain.com/api/auth/callback/social-org/linkedin - Request the
r_emailaddressandr_liteprofilepermissions - Copy the Client ID and Client Secret
Configuration in Z8
- Click Add Provider > LinkedIn
- Enter your Client ID and Client Secret
- Click Save
Apple Sign-In Setup
Apple requires additional configuration:
- Go to Apple Developer Portal
- Create a new Services ID for Sign in with Apple
- Configure the service with your domain
- Create a new Key for Sign in with Apple
- Download the
.p8private key file
Required Information
- Team ID: Found in your Apple Developer account
- Key ID: The ID of the key you created
- Private Key: Contents of the
.p8file
Configuration in Z8
- Click Add Provider > Apple
- Enter:
- Client ID (Services ID)
- Team ID
- Key ID
- Private Key (paste full contents)
- Click Save
Apple Private Key
The private key is only downloadable once from Apple. Store it securely.
Redirect URIs must match exactly
Register the callback URL for the exact domain your users sign in through. If you use multiple environments or custom domains, add the matching redirect URI for each one.
Managing Providers
The current UI lets organization admins:
- Add a provider with org-specific credentials
- Edit an existing provider
- Remove a provider
- Mark an existing provider active or inactive while editing it
The provider table can show status metadata such as Not Tested, Working, or Error, but the current product should not be treated as offering a full end-user configuration test workflow from this page.
User Experience
Login Flow
When an organization-specific provider is configured and active:
- User visits the organization's login page
- Clicks "Sign in with [Provider]"
- Redirected to provider with your org's branding
- User authenticates with their account
- Redirected back to Z8
- Account linked or created automatically
Account Linking
| Scenario | Behavior |
|---|---|
| New user, new email | New account created |
| Existing user, same email | Account linked automatically |
| Existing user, different email | User prompted to link accounts |
Security Features
PKCE (Proof Key for Code Exchange)
All OAuth flows use PKCE to prevent authorization code interception attacks.
State Signing
OAuth state is signed with HMAC to prevent CSRF attacks.
Nonce Validation
OIDC providers include nonce validation to prevent replay attacks.
Secure Cookie Storage
OAuth state is stored in secure, httpOnly cookies during the flow, while provider credentials remain stored as organization-scoped secrets in Z8.
Edit Configuration
- Open the provider row
- Click Edit
- Update the client ID, secret, or provider-specific values
- Save the changes
Delete Provider
- Open the provider row
- Click Delete
- Confirm deletion
- The custom provider is removed from the organization
User Impact
Deleting a provider doesn't affect users who have already linked accounts. They can still sign in with other methods or re-link when the provider is re-added.
Domain Restrictions
For additional security, restrict which email domains can sign in:
- Go to Settings > Enterprise > Domains
- Add your organization's email domain(s)
- Only users with matching email domains can sign in via OAuth
Troubleshooting
"Invalid redirect URI"
- Ensure the redirect URI in your OAuth app matches exactly
- Check for trailing slashes
- Verify the domain is correct
"Client ID not found"
- Double-check the Client ID is entered correctly
- Ensure the OAuth app is not deleted or disabled
"Invalid client secret"
- Regenerate the secret in the provider's console
- Update the secret in Z8 settings
- Some providers (Microsoft) require periodic secret rotation
"User not authorized"
- For Microsoft: Check the user is in the tenant
- For Google: Verify domain restrictions
- Check if the email domain is allowed
Saved configuration still fails during sign-in
- Check the redirect URI and provider credentials again
- Confirm the provider is active in the organization settings
- Verify the callback is registered for the exact domain your users sign in through