How authentik signs users in to Atlassian Cloud over SAML
If your organization already runs authentik and wants Jira and Confluence Cloud to sign users in through it instead of local Atlassian passwords, the supported route is SAML single sign-on, which the authentik integrations catalog documents for Atlassian Cloud. In this setup authentik is the SAML identity provider, and Atlassian is the service provider that trusts assertions authentik issues after a user authenticates. The integration has two hard prerequisites on the Atlassian side: an Atlassian Guard Standard subscription and a verified domain. Confirm both before scoping the work, because the verified domain is tied to DNS records that your team or the domain owner must control, and the Guard subscription is a recurring cost owned by the Atlassian organization, not by authentik or DeployOpen.
The sign-in flow itself is simple to describe and easy to get wrong in the details. A user opens a Jira or Confluence URL, Atlassian redirects the browser to authentik, authentik authenticates the user through its own flows (including any MFA stage you configure), and authentik returns a signed SAML response. Atlassian then matches that response to an Atlassian account, usually by email address, so the email attribute authentik sends must match the verified domain and the identity Atlassian already holds for that person. Your team needs to decide which authentik property mappings supply the name and email attributes, which authentication policies apply to the application, and whether users who are not in authentik can still reach the site through local Atlassian accounts. Those decisions drive most of the testing effort.
DeployOpen configures and tests the authentik side of this integration against your Atlassian organization, and it documents the settings so your administrators can maintain them. DeployOpen does not issue certifications, attestations or audit reports for the resulting setup. If a compliance assessor needs evidence of the access controls, DeployOpen can prepare the configuration records and test results, but the assessment itself belongs to an independent auditor. Ask any partner, DeployOpen included, to state in the written scope exactly which Atlassian and authentik settings will be changed, which tests will be run, and who holds the administrator access needed to make changes on each side.
What you need before configuring SAML for Atlassian Cloud
Most SAML delays for Atlassian Cloud come from missing prerequisites, not from the SAML settings themselves. The items below cover the Atlassian side, the authentik side and the people who must act on both, so the work can start in the right order.
Atlassian Guard Standard subscription
SAML single sign-on for Atlassian Cloud apps requires an Atlassian Guard Standard subscription, according to the authentik Atlassian guide. Confirm with Atlassian which plan covers the Jira, Confluence or other products in your site, and whether the subscription is attached to the right organization before you configure anything. Ask Atlassian how Guard is billed, because it is a recurring cost that continues after the integration is live.
Verified domain and DNS access
Atlassian requires a verified domain before SAML sign-in can be enforced for the email addresses on that domain. Someone with DNS control must add the verification record Atlassian provides, and that record must stay in place for the life of the integration. Confirm which domains your users actually sign in with, since users whose email addresses fall outside the verified domain will not be routed through authentik.
Supported authentik version
Run authentik on a version that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance. Check the current release list before you install or upgrade, and plan the upgrade path if your instance is on an older line.
SAML provider and application in authentik
Create a SAML provider and a matching application in authentik that Atlassian Cloud will trust. Decide which users and groups are allowed to sign in, and confirm that the email address authentik sends matches the address Atlassian holds for each user. Mismatched emails are a common cause of failed logins, so check them against a sample of real accounts before enforcing SSO.
Administrator on the Atlassian organization
Someone must hold organization admin rights in Atlassian Administration to configure the identity provider, verify the domain and set the login policy. Name a backup admin as well, because a misconfigured SAML setting can lock out every user including administrators. Agree in advance who will hold the break-glass access and where those credentials are stored.
Enterprise license only if needed
The standard SAML path does not depend on authentik Enterprise. Consider the Enterprise license only if you need a feature listed on the authentik pricing page, such as enhanced audit logging or ticket-based support, and confirm current Atlassian plan names and included features directly with Atlassian before you buy.
Configuration sequence from domain verification to first login
This sequence moves the Atlassian Cloud site from a verified domain and a working authentik SAML application to enforced single sign-on, with a pilot group confirmed at each stage.
Confirm the Guard subscription and verified domain
An Atlassian organization admin confirms that the site has an Atlassian Guard Standard subscription, which the authentik integration guide requires for SAML SSO on Atlassian Cloud apps. In the Atlassian admin console, the same admin adds the company email domain to the organization and completes DNS verification. Check: the domain shows a verified status in the admin console before any other step starts. If the domain stays unverified, stop here, because the directory cannot be configured against it.
Create the SAML provider and application in authentik
An authentik administrator follows the Atlassian Cloud guide in the authentik integrations catalog and creates a SAML provider and an application linked to it. Set the provider's ACS URL and entity ID to the values Atlassian expects, and make sure the signing certificate and the name ID mapping match the email addresses in Atlassian. Check: the provider and application appear in the authentik admin interface, and the metadata download link returns a file without errors.
Exchange metadata and entity identifiers
Export the identity provider metadata from authentik and enter the sign-on URL, entity ID and certificate in the Atlassian SAML configuration. Then take the Atlassian service provider values, including the ACS URL and entity ID, and enter them on the authentik provider. Both sides must reference the same identifiers exactly, including trailing slashes and case. Check: the Atlassian configuration screen saves without validation errors, and the authentik provider shows the Atlassian values as stored.
Configure the Atlassian SAML directory
In the Atlassian admin console, the organization admin creates a SAML directory for the verified domain and selects the authentik configuration. Decide now how new accounts will be handled, and record the user types each group will receive, because these affect how existing Atlassian accounts are matched. Check: the directory is listed as active for the domain, and the directory settings page shows the authentik values without drift from the earlier exchange.
Test sign-in with a pilot group
Add a small pilot group of named users with known accounts, both in authentik and in the Atlassian site, and have each user sign in through the Atlassian login page. Verify that authentik prompts for its own authentication, returns the user to Jira or Confluence, and that the Atlassian account matches the expected email address and user type. Check: every pilot user completes a login, and the authentik event log shows the successful SAML assertions for each of them. Record any failures before widening access.
Enforce SSO for the verified domain
After the pilot passes, the organization admin turns on enforcement for the verified domain in the Atlassian admin console so that users with that domain must sign in through authentik. Keep a named admin account outside SSO for recovery, and document how it is used. Check: a user from outside the pilot group who opens the site is redirected to authentik, and a direct password login attempt for a domain user is refused. Confirm both results in a screen capture kept with the change record.
Choosing user types and matching accounts by email
Once a domain is verified and SAML single sign-on is enforced, the question that decides whether logins succeed is whether each Atlassian account matches an identity that authentik sends. Atlassian sign-in matches on the email address in the SAML assertion, so a user who does not exist in Atlassian with that exact address, or whose address differs in case or alias from the one authentik releases, will not reach Jira or Confluence through SSO. Before cutover, export the user list from authentik, compare it with the Atlassian organization's user directory, and resolve every mismatch, including shared mailboxes, renamed staff and contractors with personal domains. Confirm in Atlassian's documentation for your plan how existing local accounts on a verified domain are converted or handled, because that behavior determines whether you must migrate accounts or can let them be created on first sign-in.
The main decision is whether every account on the verified domain goes through SSO or whether some stay outside it. Keeping a small set of accounts outside SSO, such as break-glass administrators, can preserve access during an identity outage, but it also means those accounts carry local passwords and their own second-factor setup, and they fall outside the authentik authentication policies you configure for everyone else. Moving all users in gives one control point for sign-in, MFA and offboarding, but it depends on every account existing and matching authentik before go-live. Write down which accounts, if any, are exempt, who approves each exemption, and how a review removes it. Then confirm with Atlassian which user types and admin roles apply on your Guard subscription, because the consequences of a managed account, an unmanaged account or an admin-only account differ and should not be assumed from general descriptions.
Attributes and identifiers mapped between authentik and Atlassian
This table lists each identifier and attribute authentik sends in the SAML assertion, what Atlassian Cloud expects in its place, and what must match for a user to sign in. Read it before building the authentik application, because a mismatch in the email or NameID field is the most common reason a user cannot reach Jira or Confluence after SSO is enabled. Confirm every exact value against the authentik Atlassian Cloud integration guide and your Atlassian admin settings.
| Item | authentik side | Atlassian Cloud side |
|---|---|---|
| NameID or email | Configure the NameID value in the authentik SAML provider to match the user's verified work email, per the integration guide | Atlassian matches the signed-in identity to an existing account by email on a verified domain |
| Email address attribute | Map the user's email in the SAML attribute statement under the name the Atlassian setup expects | Must belong to a domain verified in the Atlassian organization, or the user is not managed by SSO |
| First name | Map the given name attribute from the authentik user profile | Populates the display name on first sign-in; confirm which attribute name Atlassian reads |
| Last name | Map the family name attribute from the authentik user profile | Populates the display name on first sign-in; confirm the expected attribute name |
| Group attributes | Send group membership only if your Atlassian setup or access rules use it; confirm the attribute name | Groups are managed in Atlassian admin; SAML group values do not replace product access settings |
| Entity ID, ACS URL and certificate | Copy the authentik provider's entity ID, ACS URL and signing certificate from the integration guide for your tenant | Enter the authentik values in the Atlassian SAML configuration; confirm exact values in the integrations guide, not from this page |
| User type and account match | Users must already exist in authentik with the same email as their Atlassian account | Managed accounts follow the verified domain; check user types and existing accounts before enforcing SSO |
Authentication policies and hardening for Atlassian SSO
Once SAML sign-in works, the security of the Atlassian login depends on what authentik enforces before it issues an assertion and what Atlassian enforces after it. The cards below cover the controls that decide who reaches Jira and Confluence, how long sessions last, how signing material is rotated, and how org admins avoid being locked out.
Flows and MFA policies
Bind the Atlassian SAML provider to an authentication flow in authentik that requires the second factors your policy demands, such as TOTP, a hardware key or another configured stage. Check whether the Atlassian side also enforces its own verification for managed accounts, so you know which layer is the real gate. Test with an account that has no enrolled factor to confirm the flow blocks it rather than passing it through.
Restricting access to intended groups
Use an authentik policy binding on the application so that only members of the groups you name can complete SSO into Jira or Confluence. Users outside those groups should receive a denial in authentik rather than an Atlassian login error. Confirm that users who lose group membership also lose access on their next sign-in, and decide separately how Atlassian product access is removed for leavers.
SAML signing certificate rotation
The signing certificate that authentik uses to sign SAML assertions is trusted by Atlassian through the configured identity provider settings. Plan a rotation window: generate or import the new certificate, update the Atlassian side, and test a sign-in before retiring the old one. Record who owns the certificate, its expiry date and the change procedure, because an expired or mismatched certificate blocks every user at once.
Session lifetime and reauthentication
Set authentik session duration and inactivity limits to match how sensitive your Jira and Confluence content is. Atlassian maintains its own session behavior after SAML sign-in, so a shorter authentik session does not automatically end an active Atlassian session. Test both timers together and document the expected re-login interval for users and admins.
Enterprise-only controls to check
Mutual TLS client certificate authentication and enhanced audit logging are listed as Enterprise features on the authentik pricing page, not in the open-source edition. Decide whether your access review or audit requirements need them before you design the flow, because adding them later changes the subscription and the deployment. Ask authentik to confirm current edition contents for your version.
Keeping a recovery path for org admins
Before enforcing SAML, make sure at least one Atlassian organization admin can sign in without authentik, and that the account is documented and tested. Keep a second authentik administrator who can change the provider, certificate or policy bindings if the primary admin is unavailable. Store the recovery steps outside the systems they recover, and rehearse them after each certificate rotation or authentik upgrade.
Common SAML failures for Atlassian Cloud and how to fix them
This table lists the failures most often seen when authentik signs users in to Atlassian Cloud over SAML, with the likely cause and fix for each. Work through the rows in order, because a missing Guard subscription or unverified domain blocks the rest of the setup before any SAML message is exchanged.
| Failure | Likely cause | Fix and where to look in authentik logs |
|---|---|---|
| Domain not verified | The email domain has not been verified in the Atlassian admin console, so Atlassian will not route users of that domain through the SAML identity provider. | Verify the domain in Atlassian admin first, then retest. Check the authentik event log for the login attempt, which shows the email domain the user submitted. |
| Guard subscription missing | SAML SSO for Atlassian Cloud apps requires an Atlassian Guard Standard subscription. Without it, the SSO option is not available for the site. | Confirm the Guard Standard subscription is active on the organization before configuring the provider. Confirm the requirement with Atlassian and the authentik Atlassian guide. |
| Email mismatch between authentik and Atlassian | The NameID or email attribute sent by authentik does not match the email on the Atlassian user account, so Atlassian cannot link the login to an existing user. | Make sure the user's email in authentik matches the Atlassian account exactly, including case and the primary address. Inspect the SAML assertion in the authentik log to confirm the value sent. |
| ACS URL or entity ID mismatch | The Assertion Consumer Service URL or entity ID in the authentik SAML provider does not match the values Atlassian expects, so the assertion is rejected at the endpoint. | Copy the ACS URL and entity ID from the Atlassian SSO configuration into the authentik provider again. Compare them character by character, including trailing slashes. |
| Certificate mismatch or expired signing certificate | The certificate Atlassian holds does not match the signing key authentik uses, often after a certificate was rotated on one side only. | Export the current signing certificate from authentik and upload it to Atlassian. Check the authentik log for signature validation errors after each rotation. |
| Clock skew between servers | The authentik host or the identity provider clock differs enough from Atlassian's time that the assertion timestamps fall outside the accepted window. | Confirm the authentik host and its container hosts synchronize time through NTP. Look in the log for timestamp or NotBefore and NotOnOrAfter validation messages. |
| Users locked out after early enforcement | SSO enforcement was switched on before every user had a verified account, a matching email and a working authentication path, so some users could no longer log in with a password. | Keep password login available for admins and test accounts until every user has signed in successfully. Turn on enforcement only after a pilot group has completed sign-in, and keep a break-glass administrator account. |
| User type or group not assigned | The user's Atlassian account type or group membership does not grant access to the product, even though the SAML login succeeds. | Check the user's type and product access in Atlassian admin. Compare the group claims sent by authentik with the groups used for product access. |
What changes for existing Jira and Confluence data
Enabling SAML SSO does not move, convert or back up any Jira or Confluence content. Sign-in changes how users reach the site, while issues, pages, attachments and project configuration stay in Atlassian Cloud exactly as they were. That means backups and exports are a separate workstream that must be scheduled and owned before the authentik integration goes live. Confirm who on your side holds Atlassian site admin rights, since those are the accounts that can run site-level backups and exports.
Jira Cloud's backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. It does not cover automation rules, third-party apps or Assets, so teams that rely on automation or Assets need a separate inventory and a documented way to recreate those items. Check each app in use against the list in Atlassian's export documentation before you rely on the backup. For Confluence, the XML site and space export reaches end of life on December 1, 2026. After that date it still works, but Atlassian will no longer fix bugs or accept support tickets for it and recommends CSV export instead, so build your export routine around CSV and retain the other formats only as a secondary copy.
Migration to another platform is out of scope for this page. If you are considering moving Jira or Confluence content elsewhere, plan that as its own project and review the related planning topics in this section of the site before choosing a target. Ask your Atlassian contact or reseller which export formats and retention options apply to your plan, and record the answers before the SSO cutover date.
Questions buyers ask before configuring Atlassian SAML with authentik
What does Atlassian SAML SSO with authentik cost on the Atlassian side?
The main recurring Atlassian cost is an Atlassian Guard Standard subscription, which the authentik Atlassian guide names as the requirement for SAML SSO on Atlassian Cloud apps. Guard is a separate subscription on top of your Jira or Confluence plan, so it recurs for as long as you use SAML. Ask Atlassian for the current Guard price for your user count and region, because the figure depends on your contract and is not part of this page. Also confirm whether your existing Jira Cloud plan (Free, Standard, Premium or Enterprise) already includes the features you need.
Which authentik edition do I need for Atlassian SAML?
Confirm the edition against the current authentik pricing page before you commit, because the features that matter here sit in the paid tiers. The Open Source edition is free and supported through the community Discord only. The Enterprise edition is priced per user per month billed annually, plus a fee per external user, and it adds features such as enhanced audit logging and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs. Decide which support model your organization needs, since that is usually the deciding factor rather than the SAML protocol itself.
How long does an Atlassian SAML setup take?
No supplied fact gives a duration for this work, so treat any timeline as something to agree in writing rather than assume. The biggest schedule risk is domain verification on the Atlassian side, which must complete before SAML can be enforced. Other drivers are the size of the user population, how many Atlassian products are in scope, and how much cleanup of existing accounts is needed. Ask for the milestones, the dependencies on your DNS and identity team, and the point at which each side must act.
What does my team need to provide before the work starts?
You need a Guard subscription in place, control of the DNS zone for the domain you plan to verify, administrator access to your Atlassian organization, and an authentik instance you operate with a working admin account. You also need a clear list of user groups to grant access, and the names of the Atlassian products in scope. Finally, decide who owns the identity mapping between authentik accounts and Atlassian accounts, because email addresses must match for users to sign in.
Can our internal team configure Atlassian SAML with authentik without a partner?
Yes, an internal team with authentik and Atlassian administration skills can do this, provided it has the Guard subscription and the admin access listed above. The work is mostly configuration in two systems plus DNS verification and a careful test. The risks that usually need an outside check are account cleanup before enforcement, lockout recovery, and keeping a break-glass path for administrators. Compare your team's capacity against those tasks, and consider a fixed-scope engagement if the rollout must land alongside other identity changes.
What makes the effort grow for a large Atlassian rollout?
Effort rises with the number of users, the number of existing Atlassian accounts that do not match authentik identities, the number of products and sites in scope, and the number of verified domains. Each domain verification has its own lead time, so start it first. Accounts that use personal emails or shared logins need decisions before enforcement, because users who do not match will be locked out of SAML sign-in. Check how many apps sit behind the same authentik provider, since testing each app with each user group adds steps.
What should I request in a written scope for Atlassian SAML with authentik?
Ask for a scope that lists the Atlassian products, sites and verified domains covered, the authentik version and edition, and the user groups and authentication policies to be configured. Request the test plan, including a pilot group and the sign-in checks for each product, plus the rollback and break-glass procedure. Also ask for the handover deliverables, the documentation of the configuration, the account cleanup decisions, and the dependencies on DNS and Atlassian admin actions. Confirm who performs each step and which items are excluded, such as Guard licensing or the authentik edition purchase.
Does data residency change how I set up Atlassian SAML?
Data residency is a separate Atlassian setting and does not replace SAML, but it affects the decision. Atlassian lists data residency for Jira, Jira Service Management and Confluence on Standard, Premium and Enterprise plans, and it excludes user account data and connected DevOps data. It is also not available on Atlassian Government Cloud. Confirm with Atlassian which location applies to your content and whether it fits your compliance requirements before you finalize the identity design.
How DeployOpen scopes and delivers Atlassian SSO work
DeployOpen plans, implements and documents self-hosted authentik inside your own infrastructure, then connects it to your Atlassian Cloud sites as the SAML identity provider. Each engagement starts with a written scope that names the Atlassian sites, plans and domains involved, so the work and the Atlassian-side prerequisites are agreed before configuration begins.
How we scope
- Confirm the Atlassian Cloud products, sites and plans in use, including whether Atlassian Guard Standard is already active.
- Inventory the domains to verify and the email addresses each user signs in with.
- Agree how existing Atlassian user types, managed accounts and admin roles map to authentik groups.
- Record the scope, deliverables and timeline in writing before any configuration starts.
How we build
- Deploy authentik in your infrastructure, with PostgreSQL and the server and worker containers sized for your user population.
- Configure the SAML provider and application for Jira, Confluence and any other Atlassian Cloud apps in scope.
- Set authentication policies and test sign-in with admin, managed and standard accounts before switching users over.
- Test the SSO path, failure behavior and session handling against a written test plan with your team.
How we hand over
- Document the authentik configuration, Atlassian settings, verified domain steps and the policies applied to each app.
- Provide a runbook covering user onboarding, offboarding, certificate renewal and break-glass admin access.
- Walk your administrators through sign-in troubleshooting and the upgrade steps for authentik and its PostgreSQL database.
- Hand over configuration files and credentials through your own secure channels and confirm ownership in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Agree in the written scope who handles Atlassian admin changes, authentik upgrades and incident response.
- Plan authentik upgrades against the supported release lines published in the authentik security policy.
- Confirm with your team which Atlassian plan and Guard terms apply before any renewal or plan change.
