Tymeslot includes a generic OAuth 2.0 / OIDC integration that works with any standards-compliant identity provider. This is the right path when you want to enforce corporate single sign-on — routing all logins through Keycloak, Authentik, Okta, Azure AD, Lemonldap::NG, or any other IdP that supports OIDC — without needing a provider-specific plugin.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/Tymeslot/tymeslot/llms.txt
Use this file to discover all available pages before exploring further.
Supported providers
Any IdP that exposes standard OIDC endpoints works out of the box. Commonly deployed configurations include:- Keycloak (self-hosted)
- Authentik (self-hosted)
- Okta
- Azure Active Directory / Microsoft Entra ID
- Lemonldap::NG
- Any other OAuth 2.0 + OIDC-compliant provider
Redirect URI
Before configuring environment variables, register the following redirect URI with your identity provider:your-domain.com with the hostname in your PHX_HOST. Every IdP has a slightly different term for this — “redirect URI”, “callback URL”, or “allowed return URL” — but the value is always the path above.
Required environment variables
Set to
true to activate the generic OIDC login button and enable the callback endpoint. All other OAUTH_* variables are ignored unless this is true.The client ID issued by your identity provider when you registered the Tymeslot application.
The client secret issued by your identity provider. Treat this like a password and store it securely.
The base URL of your identity provider, for example
https://keycloak.example.com. This is used as a human-readable reference and may be used to construct endpoint URLs in future releases.The full authorization endpoint URL. Must use HTTPS.
The full token endpoint URL. Must use HTTPS.
The full userinfo endpoint URL. Must use HTTPS. Tymeslot calls this endpoint after exchanging the authorization code for a token in order to retrieve the user’s email and subject identifier.
Optional environment variables
Space-separated list of OAuth scopes to request. The defaults (
openid email profile) are sufficient for most OIDC providers. Override this only if your IdP requires additional scopes or uses non-standard scope names.When
true, Tymeslot will accept id or user_id as a subject claim if the IdP omits the standard sub claim. Only enable this for non-OIDC providers that do not return a sub claim. OIDC-compliant providers always include sub and do not need this flag.Example configurations
The endpoint paths below are the defaults for each platform. Your installation may use a different base URL or realm/tenant name — consult your IdP’s well-known discovery document at<provider-url>/.well-known/openid-configuration to confirm the exact paths.
- Keycloak
- Authentik
Keycloak organises clients under realms. Replace
your-realm with the realm name you created for Tymeslot, and keycloak.example.com with your Keycloak host.First, register a new Client in your realm:- Client ID:
tymeslot(or any name you choose — this becomesOAUTH_CLIENT_ID) - Client Protocol:
openid-connect - Access Type:
confidential - Valid Redirect URIs:
https://your-domain.com/auth/oauth/callback
How the login flow works
- The user clicks Sign in with SSO on the Tymeslot login page.
- Tymeslot generates a secure
stateparameter and redirects the browser toOAUTH_AUTHORIZE_URL. - The IdP authenticates the user (password prompt, MFA, etc.) and redirects back to
https://your-domain.com/auth/oauth/callback. - Tymeslot validates the
stateparameter, exchanges the authorization code for a token atOAUTH_TOKEN_URL, and fetches the user’s profile fromOAUTH_USERINFO_URL. - The
subclaim (orid/user_idifOAUTH_ALLOW_ID_FALLBACK=true) is used as the stable identifier to look up or create the Tymeslot account.
Controlling registration via SSO
TheREGISTRATION_ENABLED flag applies to OIDC login as well as email/password. If you want to allow SSO login only for pre-existing accounts and block new account creation through the IdP, set: