How authentik handles Outline SSO over OIDC
authentik acts as the OAuth2/OpenID provider and Outline is the relying party, so every sign-in is an OIDC exchange in which authentik authenticates the user and Outline trusts the result. The starting point is the authentik Outline guide in the authentik integrations catalog, which configures an OAuth2/OpenID provider in authentik for Outline's OIDC login. Your work is then split between two places: the provider and application objects in authentik, and the environment variables you pass to Outline so it knows where to send users and how to read their identity. Expect to touch both sides before the first successful login.
The integration covers the sign-in path only. Outline's hosting docs state that it does not support email and password authentication natively, and they list Google, Microsoft Entra, Slack, OIDC, Discord, GitLab, passkeys and email magic link as the supported methods. That means authentik becomes the single front door for staff accounts, and any account that does not come through the OIDC flow cannot sign in. Plan for this before cutover, including what happens to any existing Outline accounts that were created through another method, and who holds the recovery path if authentik is unavailable. Some items sit outside the guide. Outline's SAML login is limited to its licensed Business and Enterprise editions, so an OIDC setup is the route for the community edition. Team membership, sign-up restrictions and scope choices are configured in the sections that follow, not here. Confirm the current Outline environment variable names and the authentik provider settings against the Outline hosting documentation and your own Outline version before you copy values, because the guide is a starting point and your deployment may differ.
What you need before connecting Outline to authentik
Five prerequisites have to be in place before any OIDC setting is entered. Outline and authentik each need their own running stack, and the two sides must agree on a domain, a sign-in path and an administrator who can make changes on each.
Outline version and data stores
Outline runs on PostgreSQL 14 or later and Redis 4 or later, on a Unix-compatible host. Outline v1.11.0 was published on October 12, 2026, but confirm the exact version you will deploy against the releases page before you pin an image tag, since the OIDC settings you enter must match that release. Record the versions you tested so a later upgrade can be compared against them.
Memory and host sizing
Outline needs at least 512MB of memory, and 1GB or more is recommended. Size the host with headroom for the web process, background workers, PostgreSQL and Redis if they share the machine. Ask your team whether Outline's file storage will be local or S3-compatible, because that choice affects disk planning and backups.
Dedicated domain with HTTPS
Outline needs its own domain, and the OIDC redirect URI registered in authentik must match that exact address, including scheme and path. Plan the TLS certificate and reverse proxy first. A redirect URI that differs by a trailing slash or by http versus https is the most common cause of a failed first login, so confirm the final hostname before you create the provider.
Running authentik deployment
Have authentik running on Docker Compose or Kubernetes, reachable from the users who will sign in to Outline. Confirm your authentik release sits on a supported security branch, which the project lists as 2026.5.x or 2026.8.x. Plan the upgrade path now if you are on an older branch, because an unsupported release will not receive security fixes.
Administrator accounts on both sides
You need an administrator in authentik who can create providers, applications, groups and flows, and an Outline administrator who can change sign-in settings and manage teams. Keep these accounts separate from day-to-day users and record who holds them. Without both roles available at the same time, the work stalls at the first setting that needs the other side.
Outline SSO setup steps in authentik
This sequence connects Outline's OIDC login to an authentik OAuth2/OpenID provider so that users sign in with their authentik accounts. It ends with a non-admin test that confirms who can sign in and which team they land in.
Create the OAuth2/OpenID provider
An authentik administrator creates an OAuth2/OpenID provider using the settings in the authentik Outline guide, including the client type, the authorization flow and the signing key. Save the provider, then open its discovery document at the
/application/o/<slug>/.well-known/openid-configurationpath for your application slug. Done when the discovery document resolves in a browser and lists the authorization, token and userinfo endpoints.Create the application and bind it
Create the authentik application that points to the new provider, and set its launch URL to your Outline address. Bind the application only to the groups or policies that should be allowed to use Outline, because authentik enforces these bindings before the login completes. Done when a test user who should have access sees the Outline tile in their authentik library, and a user outside the bound group does not.
Set the redirect URI and scopes
Add the Outline OIDC callback URL to the provider's redirect URIs, using your own Outline domain and the callback path in Outline's authentication documentation for your version. Confirm the scopes the guide requires, typically
openid,profileandemail, and confirm which claim Outline uses for the username. Done when the provider lists exactly one redirect URI for your Outline domain over HTTPS and the scope list matches the guide.Copy the client credentials into Outline
Copy the client ID and client secret from the provider into Outline's environment configuration. Set the OIDC variables from the guide, which are expected to include
OIDC_CLIENT_ID,OIDC_CLIENT_SECRET, the authorization, token and userinfo endpoint variables,OIDC_SCOPESand a display name, and confirm each name against the authentication doc for the Outline version you run. Done when the values are set in the deployment configuration and the secret is absent from shared documents, tickets and logs.Restart Outline and check the callback
Restart the Outline service so it reads the new environment values, then open the sign-in page in a private browser window. Choose the OIDC sign-in option, authenticate in authentik, and watch the browser return to Outline without an error page. Done when the callback completes and the server logs show no token or userinfo errors for the login.
Assign teams and restrict sign-up
Decide how new users join Outline: confirm in the guide and Outline's documentation whether group claims can assign teams for your version, and whether a domain allow-list or a similar setting limits account creation. Use the authentik application bindings to control who can reach the login at all. Done when your written access rules are matched by the settings you can point to in both authentik and Outline configuration.
Test with a non-admin account
Sign in with a standard user account that is not an authentik or Outline administrator, and with one account that the bindings should block. Check that the first user is created in Outline with the expected email and name, and lands in the team you planned, while the blocked account is refused. Done when both results match the access rules and the test outcomes are recorded for the change record.
Which authentik claims map to Outline accounts and teams
This table pairs each authentik claim or attribute with the Outline account field it feeds, whether Outline needs it, and what to check on both sides. Read it before you create the provider, because the email claim decides whether a sign-in matches an existing Outline account or creates a duplicate.
| Source claim | Outline field | Required or optional | What to check |
|---|---|---|---|
| email (OIDC scope: email) | Account email | Required | Confirm the claim name and that the value matches the address already used for any existing Outline account. A mismatch in this claim is the most common cause of duplicate accounts. |
| name (OIDC scope: profile) | Display name | Required | Confirm that authentik sends the full name the way your users expect to see it in Outline, since this value is shown across documents and comments. |
| preferred_username | Username or handle | Optional | Confirm whether Outline uses this claim in your version and whether usernames are unique across your authentik users. |
| groups (custom scope mapping) | Team membership | Optional | Confirm the scope mapping that adds groups to the token, the exact claim name, and how Outline reads it. Group names must match the team mapping you configure. |
| Custom role claim (if defined) | Team role (for example admin or member) | Optional | Confirm the claim name and values against the Outline authentication doc before relying on it for role assignment. |
| sub (subject identifier) | OIDC account identifier | Required | Confirm that sub stays stable for each user. Changing the authentik user or the provider's subject setting can create a new Outline identity. |
Scopes, team assignment and how roles follow group membership
The first decision is which scopes the Outline client in authentik requests and which claims Outline reads from the login response. The OpenID Connect standard ties openid to the subject identifier, profile to name claims and email to the email address, so a login that requests only openid may leave Outline without the name or address it needs to create an account. Confirm the scope list in the authentik Outline guide against Outline's current authentication documentation, then match the scopes to the scope mappings attached to your provider. Record the exact claim names in your design document, because a later change to a mapping can break sign-in in ways that look like a directory fault.
Next, decide whether Outline teams follow authentik groups or are assigned by hand inside Outline. Automatic assignment keeps membership aligned with the identity source, but it works only if Outline can read a group claim from the login and map it to a team. Manual assignment avoids that dependency but creates a separate membership record that an administrator must maintain after every move or departure. Establish which behavior the Outline version you deploy supports, and do not assume that a group in authentik creates or renames a team in Outline until you have seen it happen in a test tenant. Also decide who may create and administer teams, since that decision determines who can change access outside authentik.
Plan for group changes and departures before rollout. In a test tenant, check three cases: a user added to a group who then signs in, a user removed from a group who already has an active Outline session, and a user disabled in authentik. For each, record whether team membership and document access change at the next login, when the session expires, or not at all, and whether an administrator must remove the membership manually. If a removed group membership changes nothing in Outline beyond the next login, include Outline's own user deactivation steps in the offboarding runbook. Repeat these checks after each Outline upgrade, because team sync behavior can change between releases.
Restricting Outline SSO sign-ups to approved users
This model suits organizations where anyone who can sign in to authentik should also have an Outline account. Entry is controlled by the authentication flow and the application's policy bindings in authentik, not by Outline itself. Outline's OIDC login creates an account when a user authenticates successfully for the first time, so the authentik side decides who reaches the login step at all.
- Where the control sits: Check the application's policy and binding settings, and the authentication flow attached to the provider, to confirm that only users who have passed your normal login and MFA stages reach Outline.
- What Outline does with an unknown user: Outline creates a new account on first successful OIDC login, using the claims the provider sends, so confirm which email and name claims your mapping returns.
- Stage checks: Make sure the enrollment and recovery flows do not allow self-registration in authentik unless you intend that outcome.
- Domain filtering: If you only want staff addresses, use an expression policy or a user attribute check in the binding rather than relying on Outline to reject addresses.
- Confirmation test: Sign in with a standard staff account and a newly created test account, then confirm both reach Outline and appear in the workspace member list.
Exact flow and binding names change between authentik releases, so confirm them in the version you run before you change anything.
This model suits smaller or sensitive workspaces where administrators decide who gets an account. Users are created in authentik ahead of time, and self-enrollment is turned off, so an authentik login only exists for people someone has approved. The control is the absence of an enrollment path, combined with a binding that limits the application to users who already exist.
- Disable enrollment: Remove or unbind the enrollment flow from the sign-in path, so that unknown visitors have no way to create an authentik identity.
- Pre-create users: Create accounts in authentik with the same email address they will use in Outline, or use an invitation if your authentik version provides that flow for your setup.
- Identity matching: Confirm that Outline keys the account on the claim you send, because a mismatch can create a second Outline account for the same person.
- Outline behavior: An invited person who authenticates for the first time still gets a new Outline account, so the invitation controls entry to authentik while Outline sets up the profile.
- Confirmation test: Attempt enrollment with an address that was never created in authentik, then confirm the login fails at authentik and Outline receives no request.
Record who created each account and when, because this model shifts the approval step into your identity administration process.
This model suits teams such as a documentation group, a security team or a pilot program, where only members of one authentik group should reach Outline. The restriction is set on the Outline application in authentik by binding a group policy, so users outside the group are stopped before the OIDC handshake completes. Outline itself does not need a group rule for this to work.
- Group binding: On the application in authentik, add a policy binding that allows only the target group, and confirm whether your version evaluates group membership through a group policy or an expression policy.
- Binding order: Check the binding order and the policy engine mode, since a permissive binding elsewhere can override the intent.
- Denied users: A user outside the group receives an access denied result in authentik, and no Outline account is created.
- Group sync to Outline: If you also need Outline roles or team membership driven by groups, treat that as a separate configuration, and confirm what claims Outline reads in your release.
- Confirmation test: Sign in as a user who is not in the group and as a member, then confirm the first is denied and the second reaches Outline.
Remember that an existing Outline account can remain in place after a user leaves the group, so review the Outline member list as part of the offboarding check.
Hardening the Outline OIDC login
The OIDC login between authentik and Outline is only as strong as the settings around it. The six controls below cover the redirect path, the client secret, the second factor, the session lifetime and the version you run, and each one is a setting you can check in both systems.
Enforce HTTPS on both ends
Serve Outline and authentik over HTTPS only, and make sure the redirect URIs registered in authentik and the Outline URL settings both use the https scheme. Mixed schemes cause redirect failures, and plain HTTP lets the authorization code and tokens travel in clear text across the network. Check that the public URLs match exactly, including host name and port, because a mismatch in either system breaks the callback.
Restrict the exact callback URI
Register only the Outline callback URL in the authentik OAuth2/OIDC provider, not a wildcard or a path prefix. A loose redirect URI lets an attacker who controls a related path receive authorization codes. Review the list after every change to the Outline domain, and remove any leftover test or staging entries.
Keep the client secret out of config
Do not place the OIDC client secret in plain compose files, Helm values or shared environment files. Store it in a secrets manager or an orchestrator secret, inject it at runtime, and restrict who can read it. Rotate it after staff changes, and record where each copy lives so a rotation reaches every deployment.
Require MFA for Outline users
Bind an authentik MFA stage to the flow that Outline users pass through, so a password alone does not reach the knowledge base. Confirm which second factors your users can enroll and whether they can skip enrollment. Test the flow with a non-administrator account, since administrator policy is often stricter than what staff experience.
Limit session lifetime and logout
Set authentik session and token lifetimes to match how sensitive your Outline content is, and confirm how Outline ends its own session when a user signs out of authentik. A session that outlives the authentik login keeps access open on shared machines. Test sign-out from both systems and confirm that disabling a user in authentik blocks new Outline sign-ins.
Run supported authentik and Outline versions
The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions that receive security fixes, and the project announces security releases at least 24 hours in advance. Track those notices, plan an upgrade window that leaves room for a rollback, and confirm that the Outline release you run is also current. Upgrade authentik one supported step at a time, and retest the Outline login after each change.
Outline SSO login failures and their fixes
This table maps common Outline sign-in failures with authentik as the OIDC provider to their likely causes and fixes. Start with the authentik event log and the Outline server logs for each row, then confirm the cause before changing settings. Most failures come from a mismatch between the redirect URI, client credentials, claims and URL scheme.
| Symptom | Likely cause | Fix |
|---|---|---|
| Redirect URI mismatch error after clicking sign in | The redirect URI registered in the authentik OAuth2/OIDC provider does not exactly match the callback URL Outline sends, often a path, trailing slash or host difference. | Check the authentik event log and Outline logs for the URL sent. Copy the callback path from the Outline integration guide into the provider's redirect URIs, then retry. |
| Token exchange fails with invalid client after a secret rotation | The client secret was rotated in authentik, but the Outline environment still holds the old value, or the container was not restarted to load the new one. | Update the client secret in the Outline environment configuration, restart the Outline service, and confirm the new value in the authentik provider settings. |
| Users sign in but land in the wrong team | Team assignment depends on claims or group values that do not match what Outline expects, or the user was created before the mapping was changed and keeps the old team. | Inspect the claims returned for a test user in the authentik event log. Correct the scope or mapping, then update the user's team in Outline's admin settings, since existing users may not be reassigned at next sign-in. |
| A second account appears for the same person | The claim Outline uses to match identities changed, for example from a username to an email address, so Outline sees a new identity instead of the existing account. | Keep the identifying claim stable across the change. Review duplicate accounts in Outline, merge or deactivate the extras, and document the claim used for matching before you change it. |
| People outside the approved group can create accounts | The sign-up restriction is not enforced because the allowed domain or group check is missing, misconfigured in the authentik policy binding, or the authentik application is bound to all users. | Bind the authentik application to the approved group only, verify the policy result with a non-member test account, and review the Outline server logs for accepted sign-ups. |
| Login loops back to the sign-in page | Outline's configured URL uses HTTP while the public address and the redirect or cookie settings use HTTPS, or the reverse proxy forwards the wrong scheme. | Set Outline's URL to the public HTTPS address, make sure the proxy passes the forwarded protocol header, and confirm the authentik redirect URI uses HTTPS. |
Questions buyers ask before connecting Outline to authentik
What does it cost to connect Outline to authentik?
The authentik side is listed as free on the authentik pricing page under Open Source, which is the edition this integration uses. The cost sits elsewhere: the time your team or a partner spends on configuration and testing, the hosting for Outline and its PostgreSQL and Redis dependencies, and ongoing upgrades to both platforms. Outline's requirements call for PostgreSQL 14 or later, Redis 4 or later, at least 512MB of memory with 1GB or more recommended, and a dedicated domain. Ask any quote to itemize who does each task, which parts are one-time (configuration, testing, cutover) and which recur (upgrades, monitoring, support). If you want Outline on a paid Business or Enterprise license, that is a separate cost to confirm with Outline directly.
How long does an authentik and Outline SSO setup take?
The duration depends on how much of the environment is new. The core task is creating an OAuth2/OpenID provider in authentik for Outline and entering the matching OIDC settings in Outline's configuration. Timing grows with the number of environments you run (for example, staging and production each need their own redirect settings), with how you design groups and which users get access, and with how many existing Outline accounts must map to the new login. Outline's authentication docs also cover other sign-in methods, so decide early whether OIDC will be the only method. Ask for a schedule that separates the test-group pilot from the production cutover.
What do we need from our own team for this integration?
Four roles usually need to be covered. An authentik administrator creates the provider, application, scopes and any group or policy bindings. An Outline administrator sets the OIDC environment variables and checks the sign-in flow. Someone who owns DNS and TLS certificates confirms the public Outline hostname and the redirect URL that authentik and Outline must agree on. A test group of real users, separate from production accounts, verifies sign-in, team assignment and sign-up restrictions before you open access. A single person can hold more than one role on a small team, but the certificate and DNS owner should be named before work starts.
Can our team connect Outline to authentik without outside help?
Yes, if your team already runs both platforms and has operations experience with each. The authentik integration guide for Outline covers the OAuth2/OpenID provider setup, and Outline's hosting docs cover the environment configuration. Outline's own documentation says it requires dev-ops experience to run in production, so the gap is usually Outline operations rather than the OIDC configuration itself. Teams without that experience should consider a fixed-scope engagement, where DeployOpen plans, implements and documents the integration in your own infrastructure with the scope and timeline agreed in writing before work starts.
Can Outline sign users in with SAML through authentik?
Only on Outline's licensed editions. Outline's SAML hosting doc states that SAML login is available in the Business and Enterprise editions, not in the community edition. If you run the community edition, use OpenID Connect, which is the protocol the authentik Outline guide covers. Before choosing SAML, confirm which Outline license you hold, because switching protocols later means reconfiguring both sides and retesting sign-in for every user group.
Can we offer Outline to our customers or partners as a hosted service?
No, not under the community license as written. Outline's community edition is licensed under the Business Source License 1.1, which forbids using it for a Document Service, meaning a commercial offering where third parties create their own teams and documents. Outline's hosting docs also state that selling, reselling or hosting Outline as a service breaches the license terms and terminates license rights automatically. Outline's license file names Apache License 2.0 as the change license with a change date of October 12, 2030. Internal use by your own organization is the scenario this integration covers. For a paid Business or Enterprise license, which adds functionality and guarantees, contact Outline and confirm terms with your legal team.
How do we limit who can sign up to Outline through authentik?
Restrict access in authentik before users reach Outline. Bind the Outline application to an authentik group or policy so only approved users receive a login, and decide whether new accounts can be created through the OIDC flow or only by an existing Outline administrator. Check the sign-in behavior in your test group before opening access, and confirm in Outline's configuration that signup from the identity provider matches your policy. Record who approved each group, because access reviews for knowledge bases often ask for that evidence.
How DeployOpen scopes and delivers the Outline SSO integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including identity integrations. For authentik and Outline SSO, we agree the OIDC provider configuration, environment variables, team assignment and sign-up restrictions in writing before work starts, then deliver and verify them in your environment.
How we scope
- Confirm your Outline license edition, since the hosting docs only describe SAML in the Business and Enterprise editions.
- Record the authentik version, the OIDC provider settings and the scopes and claims Outline will request.
- Agree in writing how teams are assigned and whether new sign-ups are limited to invited or approved users.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- Configure the OAuth2/OpenID provider and application in authentik, following the Outline guide in the integrations catalog.
- Set the generic OIDC environment variables for Outline in a test environment, then promote the same values to production.
- Test sign-in, group-to-team assignment, and the blocking of unapproved sign-ups with named test accounts.
- Keep client secrets and environment files under your secrets management practice rather than in shared documents.
How we hand over
- Deliver a written record of the authentik provider settings, redirect URIs, scopes and Outline environment variables used.
- Document the team assignment rules and the sign-up restriction settings, with the steps to change them safely.
- Walk your administrators through the sign-in test cases and the rollback steps if a login path breaks.
- Hand over the configuration so your own team can audit and reproduce it across environments.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover checking the integration after authentik and Outline version upgrades before they reach production.
- Plan an upgrade check for each Outline release, reviewing the release notes and the OIDC settings before you apply it.
- Ask any support provider to confirm which authentik and Outline versions their runbooks cover.
