SSO / OIDC Providers

Slink supports Single Sign-On through any OpenID Connect (OIDC) provider. Users sign in with an external identity provider instead of a Slink password, and accounts are matched or created automatically based on the verified email address.

Providers are configured entirely from the admin Settings page and stored encrypted in the database. There are no per-provider environment variables to manage.

Supported Providers

Slink ships with presets for the most common providers, plus a Custom option for any other OIDC-compliant service.

Provider	Issuer / Discovery URL
Google	Built in, no URL needed
Authentik	https://authentik.example.com/application/o/slink/
Keycloak	https://keycloak.example.com/realms/your-realm
Authelia	https://auth.example.com
Pocket ID	https://pocket-id.example.com
Custom	Any OIDC issuer URL

Note

Presets only prefill the provider name, icon, and scopes. Authentik, Keycloak, Authelia, Pocket ID, and Custom all use the same generic OIDC flow, so any standards-compliant provider works through the Custom option.

Adding a Provider

1. Open Settings → Single Sign-On (/admin/settings/sso).

2. Copy the callback URL shown at the top of the page and add it to your identity provider’s list of allowed redirect URIs.

   

3. Click Create, then choose a provider preset (or Custom).

4. Fill in the Issuer URL, Client ID, and Client Secret from your provider, then enable it.

   

Provider Fields

Field	Required	Description
Provider Name	Custom only	Display label for the login button.
Slug	Custom only	URL-safe identifier used in the login route. Lowercase letters, numbers, and hyphens.
Issuer URL	Yes	The provider’s base OIDC issuer. Slink appends /.well-known/openid-configuration automatically, so you do not need to include it. Not shown for Google, which uses a fixed issuer.
Client ID	Yes	OAuth client identifier from your provider. Stored encrypted.
Client Secret	Yes	OAuth client secret from your provider. Stored encrypted.
Enabled	No	Whether the provider appears on the login page.

Registration

The Registration section of the provider form controls what happens when someone signs in through this provider for the first time. Both settings default to Inherit, which follows your instance-wide configuration, so existing providers keep their current behavior.

Setting	Options	Description
New User Registration	Inherit, Allowed, Blocked	Whether a first-time sign-in can create a new account. Inherit follows USER_ALLOW_REGISTRATION. Allowed creates accounts through this provider even when public registration is disabled. Blocked restricts the provider to existing users, even when registration is enabled.
Admin Approval	Inherit, Required, Auto-approve	Whether accounts created through this provider need admin approval. Inherit follows USER_APPROVAL_REQUIRED. Required keeps new accounts pending until an admin approves them. Auto-approve activates them immediately.

Note

These settings only apply when a new account is created. Existing users, whether already linked or matched by verified email, are never affected by them.

Callback URL

Slink uses a single fixed callback path for every provider:

https://your-slink-instance.com/profile/sso/callback

The host is taken from your ORIGIN environment variable. Register this exact URL with each identity provider, or sign-in will fail with a redirect URI mismatch.

How Accounts Are Matched

Slink reads user details from the provider’s ID token. For a sign-in to succeed, the token must contain:

Claim	Purpose
sub	Stable unique identifier for the external account.
email	Used to match or create the Slink account.
email_verified	Must be true. Slink rejects sign-in if the email is unverified.
name or preferred_username	Display name. preferred_username is used as a fallback.

Email must be verified

The email address must be marked as verified by the identity provider. If the ID token is missing the email_verified claim or returns it as false, Slink throws an exception and the login fails. Make sure the account’s email is verified at your provider before signing in.

When someone signs in, Slink links the external account by sub, falls back to matching an existing user by email, and otherwise creates a new account. By default, new accounts follow your global USER_ALLOW_REGISTRATION and USER_APPROVAL_REQUIRED settings, so a first-time SSO user may need admin approval before they can sign in. Each provider can override both through its Registration settings.

Note

Slink requests the openid email profile scopes and always uses PKCE (S256). Client credentials are sent to the token endpoint using the client_secret_post method.

SSL Verification

If your provider uses a self-signed or otherwise untrusted certificate (common in local or homelab setups), Slink’s calls to the discovery, token, and JWKS endpoints will fail. Set OAUTH_VERIFY_SSL=false on the Slink container to disable certificate verification.

Variable	Description	Default
OAUTH_VERIFY_SSL	Verify the provider’s SSL certificate during the OIDC flow.Set to false only for trusted internal providers with self-signed certificates.	true

Authelia

Authelia works with Slink, but unlike most providers it does not include the email and email_verified claims in the ID token by default. Because Slink matches users by verified email, sign-in fails until you add a claims policy that puts those claims in the ID token.

Add a claims policy and reference it from the Slink client:

identity_providers:
  oidc:
    claims_policies:
      with_email:
        id_token:
          - 'email'
          - 'email_verified'
    clients:
      - client_id: 'slink'
        client_name: 'Slink'
        client_secret: '{{ env "SLINK_OIDC_CLIENT_SECRET" }}'
        public: false
        claims_policy: 'with_email'
        authorization_policy: 'one_factor'
        redirect_uris:
          - 'https://your-slink-instance.com/profile/sso/callback'
        scopes:
          - 'openid'
          - 'profile'
          - 'email'
        grant_types:
          - 'authorization_code'
        response_types:
          - 'code'

In the Slink admin form, set the Issuer URL to your Authelia base URL (for example https://auth.example.com) and use the matching Client ID and Client Secret.

Using LLDAP as a backend

LLDAP does not expose an email_verified attribute, so Authelia cannot pass it through. Define a custom claim that forces it to true:

definitions:
  user_attributes:
    always_true:
      expression: 'true'
identity_providers:
  oidc:
    claims_policies:
      with_email:
        id_token:
          - 'email'
          - 'email_verified'
        custom_claims:
          email_verified:
            attribute: 'always_true'