Skip to content

OAuth and SSO Providers

Odeion can authenticate users against third-party identity providers. When a provider is enabled, its button appears on the login page next to the password form.

ProviderWeb loginNative app loginExtra requirements
GoogleYesVia web flowNone
DiscordYesVia web flowNone
AppleYesNative sign-in sheet on iOSApple Developer account

Provider configuration lives in the database, not in a config file. Client secrets and the Apple private key are encrypted at rest and shown redacted in the admin panel after saving.

Providers are configured under Admin > Settings > Authentication. Each provider needs:

FieldApplies toDescription
Client IDAllThe application identifier issued by the provider.
Client secretGoogle, DiscordThe matching secret. Stored encrypted.
Team ID, Key ID, Private keyAppleFrom your Apple Developer account. The private key is the .p8 file contents.
Bundle IDAppleYour iOS app bundle identifier, required for native sign-in.

Every provider must be given the same redirect URI in its developer console:

https://<your-base-url>/api/auth/oauth/<provider>/callback

For example https://odeion.example.com/api/auth/oauth/google/callback. The base URL must match the Base URL in Admin > Settings > General exactly. OAuth requires the server to be reachable over HTTPS; see Reverse Proxy.

  1. Create an OAuth client ID in the Google Cloud Console (type: Web application).
  2. Add the redirect URI shown above with google as the provider.
  3. Copy the client ID and client secret into Odeion and enable the provider.

After saving, use the Test button next to the provider. It verifies that the required fields are set and that the provider’s public endpoint is reachable. A green result means the basics are right, not that a full sign-in round-trip succeeded, so finish by trying a real login.

For an identity that is already known, the OAuth flow signs the user straight in. For a new identity, the flow pauses and asks for an invite code and username before the account is created. OAuth does not bypass invite-only registration.

The pending-signup step is short-lived: the one-time exchange code issued after the provider callback expires after 60 seconds and is single-use.

The iOS app uses Apple’s native sign-in sheet instead of a browser redirect. The app sends the resulting identity token to the server for verification, and the rest of the flow (existing identity signs in, new identity needs an invite) is identical to the web flow. This requires the Apple provider to be configured with a bundle ID.