Social login
Oathvera has adapters for Google, Microsoft, Apple and GitHub. Their configured identity is exchanged for Oathvera’s own sign-in result; your application does not receive an upstream provider access token for calling Google, Microsoft or GitHub APIs.
Acceptance boundary: adapters are implemented, but the current source baseline still has a recorded outbound-network compatibility issue awaiting correction and real-provider retesting. Use the configuration instructions to prepare integrations; do not cut over a product that depends on a provider until that provider passes end-to-end acceptance.
Configure a provider
Section titled “Configure a provider”- Select your workspace in Oathvera and open Authentication. Configure the chosen provider and save its credentials through the authenticated console.
- In the provider’s developer console, create the appropriate application registration from the table below.
- Copy Oathvera’s exact callback URL into that registration. The callback shape is
<issuer>/auth/social/<provider>/callback, with provider namesgoogle,microsoft,appleorgithub. The complete issuer includes its tenant path. - Enter the matching client identifiers and secrets in Oathvera. Enable the method and confirm the consuming application’s policy permits it.
- Start sign-in from your own registered application, complete the provider flow, and verify the returned Oathvera identity and API access.
| Provider | Registration material |
|---|---|
| Web OAuth client ID and client secret; exact authorized redirect URI. | |
| Microsoft | Client ID and secret for the social adapter’s supported Microsoft identity endpoint. Use an enterprise connection for tenant-specific workforce SSO policy. |
| Apple | Services ID, Team ID, Key ID and the associated ES256 PKCS#8 private key. The adapter generates short-lived server assertions and handles the provider’s form POST response. |
| GitHub | OAuth application client ID and secret; exact callback. Identity binds to the stable provider user ID. |
Use credentials owned by the intended organization and appropriate to that provider’s account/consent settings. Provider permissions, verification requirements and supported redirect hosts can impose additional conditions; check the provider’s current registration guidance when creating the registration. Local Oathvera pages do not remove those provider restrictions.
Identity and changes
Section titled “Identity and changes”Oathvera binds an identity to the immutable provider subject. Contact email verification and account linking are separate decisions. An upstream email match never grants ownership of an existing Oathvera account by itself. Complete the explicit linking flow through an already authenticated/authorized context.
For an established provider configuration, rotate secrets while preserving the provider client identity. Replacing its client ID after users are linked can be refused because it changes the identity binding. Treat a provider-app migration as an identity migration, not a cosmetic settings edit.
Workspace configurations are shared defaults. Older application-specific provider connections can retain precedence. Review the application’s actual configuration when a method appears inconsistent with workspace defaults.
A custom authentication hostname changes the callback. Register the exact new callback with the provider and test that hostname before switching clients. Keep the original host’s configuration until its migration is accepted.
Test before relying on a provider
Section titled “Test before relying on a provider”Verify provider consent, new-account contact verification, returning users, cancellation, rejected state/nonce, explicit linking, MFA, secret rotation and custom-host callbacks. Record the provider registration and tested account categories without recording secrets or tokens. A successful branding preview is not a social sign-in test.