How authentik signs Notion users in with SAML and SCIM
If your team runs authentik and wants Notion sign-in and user lifecycle driven from it, the integration uses SAML for sign-in and SCIM for provisioning, both documented in the authentik Notion integration guide. authentik acts as the identity provider: users authenticate in authentik, Notion trusts the SAML assertion, and SCIM pushes user and group changes from authentik into the Notion workspace. The two halves have different plan requirements, so treat them as separate decisions. According to the authentik integration guide, SAML SSO requires a Notion Business or Enterprise plan, while SCIM provisioning requires Enterprise. Notion's pricing page, read in October 2026, lists Business at $20 per member per month and Enterprise by quote, with SCIM as an Enterprise-only feature. A team on Plus or Free cannot assume either capability exists, and the plan must be confirmed in the workspace before any configuration starts.
Before you build, confirm three prerequisites in the Notion workspace and in authentik. First, the workspace owner must complete domain verification, which the guide requires before SAML can be enabled. Second, decide which email domains are allowed to join, because authentik's user emails must match the verified domain or sign-in will fail for those accounts. Third, plan for exactly one SCIM API token per workspace. Generating a second token typically means one integration replaces the other, so record which authentik outpost or provider holds the token and who rotates it. Ask Notion's account team or check the current help center whether your plan includes the export controls and owner settings you intend to rely on, since the guide does not cover them. Finally, check your authentik version against the security policy before you start, because provider behavior changes between releases.
What you need before configuring Notion and authentik
Most delays in a Notion SAML and SCIM rollout come from prerequisites checked too late. Confirm the Notion plan, the domain and owner access on the Notion side, and the authentik release and network path before you touch any provider settings.
Notion plan and owner access
SAML SSO needs a Notion Business or Enterprise plan, and SCIM provisioning needs Enterprise. Confirm the plan on the workspace itself, not only on the pricing page, and confirm that the person configuring SSO is a workspace owner. Ask Notion to confirm the current plan terms before you commit to SCIM, since provisioning is the item that most often forces an Enterprise quote.
Verified domain on Notion
Notion requires domain verification before SAML SSO can be enforced, so the email domain your users sign in with must be proven to Notion first. Plan a DNS change window and identify who controls the domain's DNS records. Confirm the verification steps in the current authentik Notion guide, since the order of verification and SSO setup matters.
Supported authentik release line
Run authentik on a release line that still receives security fixes. The security policy lists 2026.5.x and 2026.8.x as supported, and security releases are announced at least 24 hours in advance. Confirm your running version against the releases page before you start, and plan the upgrade path if you are on an older line, because authentik requires sequential upgrades.
Notion callback network path
Notion must reach the authentik SAML endpoints and your authentik instance must be reachable by the browsers of users signing in. Confirm that the external hostname resolves publicly, that the reverse proxy passes the SAML paths without modification, and that clock skew on the authentik host is controlled, since SAML assertions are time-bound. Document the exact URLs authentik exposes for this application.
Certificates and trust chain
The hostname used for authentik must present a certificate that browsers trust, because a self-signed or private-CA certificate will break the sign-in redirect for users. Decide which certificate authority issues it, who renews it, and where the signing certificate for the SAML application is stored. Confirm the signing certificate options and rotation procedure in the authentik documentation for your version.
SCIM token and workspace scope
Notion issues one SCIM API token per workspace, so each workspace you provision needs its own token and its own authentik SCIM provider configuration. Decide now how many workspaces are in scope and who will hold the tokens. Store tokens in your secrets manager, not in shared notes, and record who can rotate them.
Configuring the Notion SAML and SCIM sequence
This sequence connects a Notion workspace to authentik for single sign-on and, on Enterprise, automated user provisioning, in an order that avoids the most common failed sign-ins. Each step closes with a check so the owner knows the previous step worked before moving on.
Confirm the plan and verify the domain
The workspace owner confirms the Notion plan first: SAML SSO requires Business or Enterprise, and SCIM provisioning requires Enterprise. Next, the owner starts domain verification in Notion for the company email domain, which authentik's Notion guide lists as a prerequisite before SSO can be configured. Confirm the current plan requirements on Notion's pricing page, since they are the gate for every later step. The step is done when the domain shows as verified in the workspace settings and the plan is confirmed in writing for your procurement record.
Create the SAML application in authentik
An authentik administrator creates a SAML provider and application for Notion, following the Notion guide in the authentik integrations catalog. Set the audience, ACS URL and signing settings that the guide specifies, and map the email attribute that Notion will match against existing member accounts. Assign the application only to the users or groups who should reach the workspace in the first rollout. The step is done when the provider saves without errors and the metadata or SSO values are available to copy.
Enter the SSO values in Notion
The workspace owner enters the SSO URL, certificate and other values from authentik into Notion's SAML SSO settings, then enables SAML for the workspace. Keep the owner's existing password-based access available until the test in the next step succeeds, so an error does not lock out every administrator. Record which authentik provider and certificate were used so future rotations are traceable. The step is done when Notion saves the configuration and shows SAML as enabled for the workspace.
Test sign-in with a non-admin account
Sign in to Notion through authentik using a test account that is a regular member, not a workspace owner or admin. Confirm the user lands in the correct workspace, that the email matches the existing member record, and that the session is not blocked by the verified domain check. If the test fails, check the email attribute mapping in authentik and the domain verification status before changing other settings. The step is done when the non-admin test account signs in through SSO and reaches the workspace without a manual override.
Set allowed email domains
Once SSO works, the owner restricts which email domains may join the workspace so that only verified company addresses are accepted. Review existing members on external domains and decide whether they should be removed, converted or kept as guests before the restriction takes effect. Confirm with the identity team which domains are in scope, including any subsidiary or legacy domains. The step is done when the allowed domain list matches the approved list and a test invitation from an unlisted domain is refused.
Generate one SCIM token per workspace
On an Enterprise plan, the owner generates a SCIM API token in Notion for this workspace only, since Notion requires one token per workspace. Store the token in your secrets manager, not in a ticket or chat, and record its owner and expiry process. In authentik, create the SCIM provider for Notion using the token and endpoint from the guide, then bind it to the same application used for SAML. The step is done when authentik reports the SCIM connection as healthy and the token is stored outside the configuration files.
Confirm sync of one test user
Create or assign one test user in authentik and let provisioning push that account to Notion. Check that the account appears in the Notion member list with the expected name and email, and that its group or role mapping matches the design. Then remove the test user from the authentik assignment and confirm the account is deactivated in Notion, which proves the deprovisioning path works before wider rollout. The step is done when both the create and the removal are visible in Notion and in the authentik sync logs.
Which Notion plan fits SAML only and SAML plus SCIM
The Business plan supports SAML SSO through authentik, so users who sign in through authentik reach the workspace with their company identity. Provisioning stays outside the SSO flow on this plan. Workspace admins still invite members, assign them to teams and remove them when they leave, unless they run that process by hand against the workspace member list.
- Sign-in control: authentik decides who can authenticate and which MFA rules apply, while Notion accepts the SAML assertion.
- Membership stays manual: new hires must be added to the workspace by an admin, and leavers must be removed by an admin.
- Lower subscription cost: Business is listed at $20 per member per month on the Notion pricing page as read in October 2026, so this is the entry point for SAML.
- Offboarding gap: disabling a user in authentik blocks new sign-ins, but an existing Notion membership remains until an admin removes it.
- Smaller admin change: the admin process changes less, so the main work is the SAML configuration and domain verification.
Confirm with Notion's current plan documentation that SAML on Business covers your workspace configuration before you commit.
The Enterprise plan adds SCIM provisioning on top of SAML, which lets authentik create, update and deactivate Notion users as their status changes in the directory. Each workspace needs its own SCIM API token, so the token is generated in Notion and configured in authentik for that workspace. Enterprise pricing is by quote, so the cost depends on the scope agreed with Notion.
- Automated lifecycle: group and user changes in authentik flow to Notion without a manual admin step.
- Per-workspace token: each workspace needs one SCIM token, so multiple workspaces mean multiple tokens to rotate and track.
- Quoted pricing: Enterprise is not listed with a price, so request a written quote that covers seats, support and any security features you need.
- Admin role change: admins shift from adding and removing people to reviewing group mappings and token health.
- Deprovisioning path: leavers are deactivated through the lifecycle process rather than relying on a manual removal.
Ask Notion which SCIM behavior and group mapping its Enterprise plan supports before you finalize the design.
The choice depends on how often membership changes and how much risk a stale account carries. A workspace with a small, stable membership may accept manual removal on Business. A workspace holding sensitive pages, or one where people join and leave frequently, usually needs the Enterprise lifecycle path. The decision is less about SAML itself, which both plans can use for sign-in, and more about who owns the offboarding step.
- Membership churn: frequent joiners and leavers favor SCIM.
- Content sensitivity: exports and sharing settings matter more when many people hold access.
- Admin capacity: a manual process needs a named owner and a recurring review.
- Budget process: Business has a published per-member price, while Enterprise needs a quote.
- Upgrade path: starting on Business and moving to Enterprise later is possible, but confirm the plan change steps with Notion.
Record the decision and the owner of offboarding in your access policy before rollout.
Mapping authentik users and groups to Notion members
This table compares the authentik attributes that feed Notion identity matching, provisioning and access control. Read each row as a question to settle with your Notion workspace owner before the first test login, because a mismatch in one field can block sign-in or create a duplicate member.
| Attribute or setting | What it controls in Notion | What to confirm before go-live |
|---|---|---|
| Email address | Primary matching key between the authentik user and the Notion member record | Confirm that every authentik account uses the same primary email as the Notion account, including case and aliases |
| Allowed email domains | Which email domains may join the workspace through SSO | Confirm the list matches verified domains only and that personal domains are excluded |
| Name fields (given and family name) | Display name shown for members after sign-in or provisioning | Confirm which authentik attributes map to name fields in the integration and test with one sample user |
| Group membership | Potential source for role or team assignment if the integration supports group mapping | Confirm with the authentik Notion guide whether groups map to Notion roles or only drive provisioning scope |
| Workspace role (owner, admin, member, guest) | Permissions a member receives after joining, which authentik may not set directly | Confirm whether roles are set in Notion after provisioning and who keeps that process current |
| SCIM deprovisioning state | Whether a deactivated authentik user is removed or loses access to the workspace on Enterprise | Confirm the expected behavior for leavers and who owns the review of orphaned pages and content |
Securing the Notion SCIM token and sign-in path
The SCIM token, the allowed email domains and the sign-in policy all decide who can reach a Notion workspace after authentik is connected. Each control below can be checked in authentik and in Notion's admin settings, so the team can confirm it before go-live and after every change.
Scope and store the SCIM token
Notion issues one SCIM API token per workspace, and that token can create, change and remove members. Store it only in a secret store your platform team controls, and enter it into the authentik SCIM provider rather than into tickets, wiki pages or chat. Confirm that only the named integration owners can read the secret, and that the token is not written into exported configuration files or backups without encryption.
Rotate the token on a planned schedule
Treat the SCIM token as a credential with an owner and a rotation procedure. Generate a replacement in Notion, update the authentik provider, run a test sync, and then revoke the old token. Record who performed each rotation and when. Ask your Notion admin how the old token is revoked, because a token left active after a staff change is a common gap.
Restrict the owner account
The workspace owner account is the most privileged identity in the Notion workspace. Keep it separate from daily user accounts, protect it with a hardware-backed second factor, and limit how many people hold owner rights. Confirm in Notion who the owners are before enabling SCIM, because provisioning changes made under an owner's session are attributed to that person.
Limit allowed email domains
Use the verified domain and the allowed email domain settings so that only identities from your verified domain can join the workspace through SSO. Test with an address from a domain you do not own to confirm it is refused. Any personal or guest email domain you allow needs a documented business reason and an owner.
Enforce MFA in authentik
Notion does not enforce your second factor for SSO users, so the MFA decision belongs in authentik. Attach an authenticator validation stage to the authorization flow used by the Notion application, and confirm that a sign-in without the factor is rejected. Test the path after any flow change, since an edited stage can silently remove the check.
Disable exports on Enterprise
On Enterprise, Notion lets admins disable exports in the workspace security settings. Decide whether bulk exports should be allowed for your classification of content, then confirm the setting in the admin console and test it with a non-owner member. Note that Include subpages PDF export depends on plan, so verify export behavior on your own plan before relying on either control.
Notion and authentik failures and how to fix them
This table lists the failures teams most often hit when connecting Notion to authentik, with the likely cause and the fix for each. Read it as a checklist: confirm the plan and domain first, then the email domain rules, the SCIM token, and finally certificates and clock settings.
| Failure | Likely cause | Fix |
|---|---|---|
| SAML option is missing in Notion | The workspace is on the Free or Plus plan. SAML SSO starts on Business, per Notion's pricing page. | Confirm the workspace plan as a workspace owner. Upgrade to Business or Enterprise before configuring SAML in authentik. |
| SAML sign-in cannot be enabled | The email domain is not verified in Notion yet. The authentik guide requires domain verification first. | Add the DNS record Notion provides for your domain, wait for verification, then return to the SSO settings. |
| Some users are blocked at sign-in | Allowed email domains in Notion do not include the address the user signs in with, such as an alias or a subsidiary domain. | Compare the user's email in authentik with the allowed domain list. Add the missing domain or correct the user's primary email. |
| SCIM users do not sync | The SCIM token belongs to a different workspace, or the workspace is not on the Enterprise plan. SCIM provisioning is Enterprise only. | Generate one SCIM API token per workspace in the correct workspace, store it in the authentik SCIM provider, and confirm the Enterprise plan. |
| Sign-in loops back to the login page | The signing certificate in authentik does not match the one Notion has, or the certificate was rotated on one side only. | Re-export the certificate from authentik and upload it again in Notion. Check that the entity ID and ACS URL match the values in the guide. |
| SAML assertion is rejected as expired or not yet valid | Server clocks in authentik or the identity path are out of sync, so timestamps fall outside the allowed window. | Check time synchronization on the authentik hosts and any upstream identity source. Retry after clocks are corrected. |
| Deprovisioned users keep access | SCIM is not running, so removals in authentik never reach Notion, or the user remains active in a different workspace. | Confirm the SCIM sync status and the token scope, then review the workspace member list after a test removal in authentik. |
Questions teams ask before connecting Notion to authentik
Which Notion plan do we need before authentik can sign users in?
SAML single sign-on requires a Notion Business or Enterprise plan, according to the authentik integrations guide for Notion. SCIM provisioning, which creates and removes users automatically from authentik, is available only on Enterprise. Notion's pricing page, as read in October 2026, lists Business at $20 per member per month and lists Enterprise by quote. Confirm current plan names, per-seat pricing and whether SAML is included on your existing plan with Notion before you commit budget, because Notion can change its tiers.
How much does the Notion side of this integration cost?
The Notion cost is a recurring seat subscription paid to Notion, and it scales with the number of members who need a paid plan. The authentik Open Source edition is free to use, but the authentik Enterprise subscription is priced at $5 per user per month billed annually, plus $0.02 per external user per month, according to the authentik pricing page. Those authentik figures apply only if you need features that sit in the Enterprise edition, such as certain integrations or enhanced audit logging. Ask Notion for a written quote for the seat count and plan you need, and check whether your authentik edition matches the features in this guide.
How long does a SAML and SCIM setup for Notion usually take?
No duration is published in the sources for this integration, so treat any number as something to confirm rather than a plan. Effort depends on how many steps are new to your team: domain verification in Notion, the allowed email domains, creating the SAML application in authentik, and generating a SCIM API token for the workspace. Teams that already run authentik and control their Notion workspace typically spend most of their time on testing with a small group first. Ask your implementation partner for a written timeline tied to the scope, and ask which steps depend on Notion support responses.
What access must we have before starting the Notion integration?
You need four things before work starts:
- Owner access to the Notion workspace, so you can verify the domain, configure SAML and generate a SCIM token.
- Administrator access to your authentik instance to create the provider, application, groups and policies.
- Control of the DNS records for the domain you will verify with Notion.
- A small test group of real users with known email addresses, used to check sign-in and provisioning before wider rollout.
The authentik integration guide for Notion says domain verification is required first, so confirm DNS access early because it often gates the rest of the work.
Can our own team set up Notion SAML and SCIM without outside help?
Yes, a team with authentik administration experience and Notion workspace ownership can complete this setup in-house, because the steps are documented in the authentik integrations guide and Notion's help pages. The main risks are the plan decision, the one SCIM token per workspace rule, and deprovisioning behavior when someone leaves. A partner is useful when the team lacks authentik experience, needs a fixed-scope written plan, or wants testing and handover documented. DeployOpen works on fixed-scope engagements agreed in writing before work starts, so you can compare an in-house plan with an external one on the same scope.
How does an Enterprise quote change the total budget?
An Enterprise quote changes the budget in two places: the Notion Enterprise seat price, which Notion sets by quote, and the authentik side, if your edition or features require an Enterprise subscription. Notion lists Enterprise by quote and SCIM provisioning is Enterprise only, so a team that wants automatic provisioning should expect the quote to be the largest recurring line. Ask Notion for a quote that names the plan, seat count, billing period and any security settings you need, such as export controls. Ask the implementation side for a separate line for one-time setup and a separate line for recurring support.
What goes wrong if we skip SCIM and rely on SAML only?
Without SCIM, users can sign in through authentik over SAML, but their Notion accounts are not created or removed by the identity provider. Leavers may keep workspace access until an admin removes them manually, which is a common audit finding for access reviews. SAML alone suits a smaller workspace with few joiners and leavers, while SCIM suits an organization that needs timely deprovisioning. Confirm which of your controls require automated removal before choosing the plan, because the SCIM requirement changes the Notion tier you need.
Does the Notion export feature affect this integration project?
Yes, export settings matter in two ways. Notion says exporting all workspace content can take up to 30 hours, so plan exports separately from the identity work if you need backups before a cutover. Notion also allows Enterprise workspaces to disable exports in security settings, which may conflict with a data handling policy you set during rollout. Decide your export and retention rules with the Notion owner before enabling SSO, so the security settings match your policy from the first login.
What a fixed-scope Notion integration covers
A fixed-scope Notion integration starts with a plan confirmation, because the work depends on the workspace tier. SAML SSO requires a Notion Business or Enterprise plan and SCIM provisioning requires Enterprise, so the first deliverable is a written record of which plan the workspace is on, which features that plan allows and which ones must be bought before configuration starts. Domain verification comes next. Notion requires the domain to be verified before SSO can be enabled, so the scope should state who holds access to the DNS records for the domain and who will complete the verification step on the Notion side.
The configuration work covers the authentik side and the Notion side. On authentik, the scope typically includes the SAML provider and application, the signing settings, the attribute mappings that carry the email address Notion matches on, and the SCIM provider with its connection to the Notion workspace. On the Notion side, it includes the SAML settings, the allowed email domains and the single SCIM API token generated for that workspace. Test users are then signed in through a sandbox group, and the scope should name who approves the test results and how failed sign-ins are logged and retried before rollout.
Rollout moves from pilot groups to the full workspace, and the agreed scope should end with handover notes. Those notes should record the plan tier, the verification record, the token owner and its rotation process, the group assignments that drive provisioning and the steps for deprovisioning leavers. Scope, deliverables and timelines are agreed in writing before work starts, so ask for the plan confirmation, test plan and handover list to appear as named deliverables in the quote, and confirm with your Notion account team any plan change that the scope depends on.
How DeployOpen scopes and supports the Notion integration
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik as the identity provider for Notion. We start from your Notion plan, verified domains and provisioning requirements, then agree the work in writing before any configuration begins.
How we scope
- Confirm your Notion plan tier, since SAML needs Business or Enterprise and SCIM needs Enterprise.
- Record domain verification status, allowed email domains and which workspaces need their own SCIM token.
- Agree in writing which authentik version, hosting model and deliverables are covered. Engagements are fixed-scope.
How we build
- Configure the authentik SAML provider and application for Notion, mapping attributes to the Notion user profile.
- Set up SCIM provisioning only where the workspace plan supports it, with one token per workspace.
- Test first sign-in, group and deprovisioning behavior in a staging workspace before changing production.
How we hand over
- Document each authentik provider, mapping, token location and the Notion settings changed.
- Walk your administrators through adding users, removing leavers and rotating SCIM tokens.
- Record open items, such as export settings and owner account decisions, for your own review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover authentik version upgrades and changes to Notion plan or admin settings.
- Ask for the support scope and response terms in the written quote, since these are agreed per engagement.
