Connect Authentik

Authentik connects as a generic OpenID Connect provider. This page covers the Authentik side and the defaults that block sign-in. The protocol settings, the warnings and the sign-in refusals are on Connect an OpenID Connect provider.

Authentik ships two defaults that stop a connection working, so read signing key and email verified before you test a sign-in.

Create the provider and application

In Authentik, a provider holds the OpenID settings and an application makes it visible. Create both.

1. Applications → Providers → Create, type OAuth2/OpenID Provider.
2. Client type: Confidential. Copy the generated Client ID and Client Secret.
3. Redirect URIs: the redirect URI shown next to the connection at Settings → Single sign-on in deploybase. It is the sign-in service’s callback, not a deploybase address. Add it as a strict match rather than a regular expression.
4. Signing Key: pick a certificate. See signing key below; this is the field that is empty by default and breaks sign-in.
5. Advanced protocol settings → Scopes: leave the default openid, profile and email mappings in place.
6. Save, then Applications → Applications → Create, give it a slug such as deploybase, and select the provider you just made.

The application slug appears in the issuer URL, so pick it before you copy the issuer.

Find the issuer URL

Authentik gives each provider its own issuer, built from the application slug, and it ends in a trailing slash:

https://id.example.com/application/o/deploybase/

Take the value from the provider page rather than typing it: open the provider and follow the OpenID Configuration URL. The issuer field of that document is the exact value.

The trailing slash is real. It is what Authentik puts in the token’s iss claim, and sign-in compares the two strings exactly. Entering the URL without the slash is the single most common mistake here, so it is not treated as an error: the provider’s spelling is stored and the connection tells you the value was adjusted.

Issuer mode

Authentik has an Issuer mode setting on the provider, under Advanced protocol settings. It has two values:

• Each provider has a different issuer (per-provider). Use this one.
• Same identifier for all providers (global). This reports one shared issuer for the whole installation, so every application claims to be the same provider.

The global mode cannot be brokered. The discovery document still lives at the per-application path, while the iss claim carries the installation-wide value, so the two never agree and sign-in fails at token verification. The connection is refused at save time with a message naming this setting, rather than left to fail at someone’s first sign-in.

Open the provider, set Issuer mode to “Each provider has a different issuer”, save, and try the connection again. If other systems depend on the global issuer, give deploybase its own provider with its own application slug instead of changing the shared one.

Signing key

A new Authentik provider has no Signing Key selected. With the field empty, Authentik signs ID tokens with the client secret using HS256, and the sign-in service verifies asymmetric signatures only: it fetches your public keys from the JWKS endpoint, and there is no public key for an HMAC signature. No sign-in can ever succeed, so the connection is refused rather than saved with a warning.

The fix is one field. Open Applications → Providers → your provider, set Signing Key to a certificate (the built-in self-signed authentik Self-signed Certificate is fine, since only Authentik’s own public key is used to verify), and save. Authentik then signs with RS256.

Re-test the connection in deploybase afterwards. The discovery document changes as soon as the key is set.

Email verified

Authentik 2025.10 and later report email_verified: false for every user by default, whatever the account’s real state. The default email scope mapping does not emit a verified flag, and the missing flag reads as unverified.

Sign-in matches people by a verified address, so on a stock Authentik every member is refused. The warning is raised on every Authentik connection for this reason: it is not something we can see from the discovery document, and it costs an afternoon to find.

Two ways forward:

1. Customise the email scope mapping in Authentik. Under Customisation → Property Mappings, edit the scope mapping for email so it returns email_verified as true for the accounts you trust. This keeps the claim honest and is the better answer where your directory really does verify addresses.
2. Turn on Trust unverified email addresses on the connection. Addresses from this Authentik are then accepted whether or not it calls them verified. Only the team Owner can turn it on, because anyone who can set an address in that Authentik can then sign in as the holder of that address in your team.

Pick the second option only where you control who can register and change addresses in that Authentik installation.