Google OAuth App Setup
Set up a Google OAuth app in Google Cloud Console. One app powers Google Login, Calendar sync, and Meet rooms for Tymeslot. Covers API enabling and consent screen.
Connect Tymeslot to any OAuth 2.0 / OpenID Connect identity provider for single sign-on, including Keycloak, Authentik, Lemonldap::NG, Okta and Microsoft Entra ID.
Mis à jour le 4 mars 2026
By the end of this guide, users can sign in to Tymeslot through your organisation's identity provider, alongside or instead of email and password.
Tymeslot uses the standard OAuth 2.0 Authorization Code flow, with PKCE. When a user clicks the SSO button:
sub
(subject) claim.
sub, email, email_verified, name) from the userinfo endpoint. The
sub
claim is required.
Create a new OAuth 2.0 / OIDC client application in your IdP. The steps depend on the provider, but you typically supply:
Tymeslot
https://yourdomain.com/auth/oauth/callback
openid email profile
After creating the client, note down the Client ID and Client Secret.
You need three endpoint URLs from your identity provider. Most OIDC providers publish them in their discovery document at:
https://your-idp.example.com/.well-known/openid-configuration
From the discovery document (or your IdP's documentation), note:
authorization_endpoint)
token_endpoint)
userinfo_endpoint)
Add the following to your Tymeslot environment and restart it.
# Enable generic OAuth / OIDC SSO
ENABLE_OAUTH_AUTH=true
# OAuth client credentials (from Step 1)
OAUTH_CLIENT_ID=your-client-id
OAUTH_CLIENT_SECRET=your-client-secret
# Identity provider URLs (from Step 2)
OAUTH_PROVIDER_URL=https://your-idp.example.com
OAUTH_AUTHORIZE_URL=https://your-idp.example.com/authorize
OAUTH_TOKEN_URL=https://your-idp.example.com/token
OAUTH_USERINFO_URL=https://your-idp.example.com/userinfo
# Scopes (optional — defaults to "openid email profile")
# OAUTH_SCOPE=openid email profile
OAUTH_AUTHORIZE_URL, OAUTH_TOKEN_URL, and
OAUTH_USERINFO_URL
must use HTTPS (or be paths relative to OAUTH_PROVIDER_URL). Tymeslot refuses to start if any of them uses plain HTTP, because they carry authorisation codes, client credentials and access tokens.
After the restart, an SSO
button appears on the sign-in and sign-up pages. While the variable is unset, an admin can also turn SSO on or off later in the admin panel's
Authentication
tab, without a restart. On Cloudron, the OIDC addon supplies these values and SSO is on automatically unless you set ENABLE_OAUTH_AUTH=false. If the log shows "No admin can sign in" at startup, an environment variable such as that one is pinning a sign-in setting; unset or correct it and restart.
Below are example configurations for common identity providers. Replace the placeholders with your own credentials and domain.
ENABLE_OAUTH_AUTH=true
OAUTH_CLIENT_ID=tymeslot
OAUTH_CLIENT_SECRET=your-keycloak-client-secret
OAUTH_PROVIDER_URL=https://keycloak.example.com
OAUTH_AUTHORIZE_URL=https://keycloak.example.com/realms/your-realm/protocol/openid-connect/auth
OAUTH_TOKEN_URL=https://keycloak.example.com/realms/your-realm/protocol/openid-connect/token
OAUTH_USERINFO_URL=https://keycloak.example.com/realms/your-realm/protocol/openid-connect/userinfo
ENABLE_OAUTH_AUTH=true
OAUTH_CLIENT_ID=your-authentik-client-id
OAUTH_CLIENT_SECRET=your-authentik-client-secret
OAUTH_PROVIDER_URL=https://authentik.example.com
OAUTH_AUTHORIZE_URL=https://authentik.example.com/application/o/authorize/
OAUTH_TOKEN_URL=https://authentik.example.com/application/o/token/
OAUTH_USERINFO_URL=https://authentik.example.com/application/o/userinfo/
ENABLE_OAUTH_AUTH=true
OAUTH_CLIENT_ID=your-lemonldap-client-id
OAUTH_CLIENT_SECRET=your-lemonldap-client-secret
OAUTH_PROVIDER_URL=https://auth.example.com
OAUTH_AUTHORIZE_URL=https://auth.example.com/oauth2/authorize
OAUTH_TOKEN_URL=https://auth.example.com/oauth2/token
OAUTH_USERINFO_URL=https://auth.example.com/oauth2/userinfo
When a user clicks SSO, Tymeslot sends them to your identity provider's sign-in page. Once they have signed in there, the IdP sends them back to Tymeslot, which signs them in.
On first sign-in, Tymeslot sets up a new account from the email and name in the IdP's userinfo response. Whether it trusts that email straight away depends on OAUTH_EMAIL_VERIFIED_CLAIM: by default (trust_absent) an email counts as verified unless the IdP sends email_verified: false, which suits Authentik, Entra ID and Keycloak setups that omit the claim. Set it to
require
to accept only email_verified: true, or
ignore
to trust every email your IdP returns. An email that is not trusted must be confirmed through a link Tymeslot sends.
SSO users cannot set or reset a password in Tymeslot, because the identity provider handles sign-in. Their account settings page marks the password as managed by the provider and offers no password change.
SSO button does not appear on the login page
Confirm that
ENABLE_OAUTH_AUTH=true
is set and that you restarted Tymeslot, because environment variables are only read at startup. If the variable is unset, check that an admin has not switched SSO off in the admin panel's Authentication tab.
"SSO authentication failed" after clicking the button
Check the Tymeslot server logs for the specific error. The most common causes are an incorrect OAUTH_TOKEN_URL, a wrong client secret or a redirect URI mismatch. The callback URI registered in your IdP must be exactly https://yourdomain.com/auth/oauth/callback.
"invalid_user_info" error in server logs
The userinfo endpoint must return a JSON object containing a unique user identifier. Tymeslot requires the standard
sub
claim by default. If your IdP returns
id
or user_id
instead, set
OAUTH_ALLOW_ID_FALLBACK=true
to accept those claims. Without this flag, sign-in fails if
sub
is missing.
Tymeslot fails to start with a configuration error
When ENABLE_OAUTH_AUTH=true, Tymeslot checks at startup that every required variable is set. If any are missing, it refuses to start and prints the missing names. Set all of the following: OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, OAUTH_AUTHORIZE_URL, OAUTH_TOKEN_URL, OAUTH_USERINFO_URL, and
OAUTH_PROVIDER_URL
when any of those endpoints is a relative path.
Yes. All three can be on at once, each with its own button on the sign-in page. Each Tymeslot account belongs to one sign-in method, and an email address can only belong to one account, so a user who first signed in with Google cannot later sign in with SSO using the same email.
No. SSO users have no Tymeslot password. If one requests a reset, the form answers as it does for any address, and Tymeslot emails them to explain that they sign in through SSO. Passwords are managed in your identity provider.
Yes. Set
REGISTRATION_ENABLED=false
to hide the email sign-up form. Existing users can still sign in with SSO, but new SSO users cannot create accounts either, because the setting closes registration for every method. To keep SSO as the only sign-in method for existing accounts, also set PASSWORD_AUTH_ENABLED=false.
Tymeslot reads four claims:
sub
(required unless
OAUTH_ALLOW_ID_FALLBACK
is enabled), email, email_verified, and name. If
email
is missing, Tymeslot asks the user for one during sign-up.
No. You set each endpoint URL explicitly in an environment variable, which also works with providers that publish no discovery document.
Yes, but Tymeslot has only one generic SSO provider. If you change the IdP (for example, from Keycloak to Authentik), existing SSO accounts no longer match because the user identifiers (sub
claims) differ between providers. Before switching, remove or reassign the old SSO accounts in the database. Users then get new accounts when they first sign in through the new IdP.
Set up a Google OAuth app in Google Cloud Console. One app powers Google Login, Calendar sync, and Meet rooms for Tymeslot. Covers API enabling and consent screen.
Register an Azure app for Tymeslot. Enables Outlook Calendar sync and Teams meetings. Covers API permissions and admin consent requirements.
Let your team and customers sign in to Tymeslot with their GitHub account. Create an OAuth app, set two environment variables, and you're done.