Atlassian (Jira / Confluence) SSO with MojoAuth
Connect Atlassian cloud (Jira, Confluence, Bitbucket) to MojoAuth using SAML 2.0 through Atlassian Guard (formerly Atlassian Access). MojoAuth is the Identity Provider (IdP); Atlassian is the Service Provider (SP). Once configured, SSO applies to every managed account on your verified domain across all Atlassian cloud products — not just one site.
How it works
Atlassian Guard centralizes SSO at the organization level (admin.atlassian.com), not per-product — so this one connection covers every cloud site under your verified domain(s).
Prerequisites
- An Atlassian Guard subscription on your Atlassian organization. SAML SSO is a Guard feature — it is not available on plain free/standard Jira or Confluence without it.
- At least one verified domain on the organization (Directory → Domains), with managed accounts for the users you want to put behind SSO. Unmanaged accounts (personal emails not on a verified domain) cannot be forced through SSO.
- Organization admin access at
admin.atlassian.com. - A MojoAuth project (test or live) with permission to create a new SAML connection.
Domain verification can take time to propagate (DNS TXT record or HTML file check). Verify your domain and confirm accounts show as managed before you start the SAML configuration — Atlassian will not let you enforce an SSO policy on unmanaged users.
Step 1 — Create the MojoAuth SAML connection
In the MojoAuth dashboard: Developers → Applications → New Application → SAML 2.0 SSO. Enter a connection name (e.g. Atlassian) and click Create connection. This creates a draft connection and immediately issues its IdP signing certificate — you don't need Atlassian's details yet.
See SAML SSO Connections for the full concept doc if this is your first connection.
Step 2 — Configure Atlassian Guard
Open the SAML configuration screen
Go to admin.atlassian.com → select your organization → Security → SAML single sign-on → Add SAML configuration.
If SAML single sign-on isn't visible, your organization doesn't have Atlassian Guard yet, or the domain you intend to enforce SSO on isn't verified. Fix that first — the option only appears once a verified domain exists.
Enter MojoAuth's IdP details
Atlassian's form asks for three values — copy them from the MojoAuth connection page:
| Atlassian field | MojoAuth value |
|---|---|
| Identity provider Entity ID | {BASE}/saml/{projectId}/sps/{spId}/metadata (the IdP metadata URL) |
| Identity provider SSO URL | {BASE}/saml/{projectId}/sps/{spId}/sso |
| Public x509 certificate | Paste the PEM from Copy PEM (or open the downloaded .crt) on the MojoAuth connection page |
Paste the certificate as plain PEM text into the Public x509 certificate box — Atlassian expects
the raw -----BEGIN CERTIFICATE----- block, not a file upload.
Save the configuration
Click Save configuration. Atlassian validates the metadata URL and certificate, then generates its own SP details for you to send back to MojoAuth.
Step 3 — Give Atlassian's SP details back to MojoAuth
After saving, Atlassian displays:
| Atlassian shows | Give to MojoAuth as |
|---|---|
| SP Entity ID (Audience URL) | SP Entity ID |
SP Assertion Consumer Service URL — e.g. https://auth.atlassian.com/login/callback?connection=saml-<org-id> | ACS URL |
Back on the MojoAuth connection page, use Manual configuration and paste these two values in (Atlassian doesn't publish a fetchable SP metadata document, so "Import from metadata" isn't available for this provider — enter them by hand), then Save.
The ACS URL is unique per organization (it embeds your connection=saml-... ID) and per SAML
configuration — if you ever delete and recreate the SAML configuration in Atlassian Guard, the ACS
URL changes and you must update the MojoAuth connection to match.
Step 4 — Attribute mapping (NameID)
Atlassian identifies users by email address — it does not read custom SAML attributes for
provisioning (accounts must already exist as managed accounts on the verified domain; Atlassian
matches the incoming assertion to that account by NameID/email). Configure the connection's NameID
format as emailAddress, with source = email:
| Field | Value |
|---|---|
| NameID format | emailAddress |
| source | email |
You don't need additional attribute mapping rows for Atlassian — no saml_name attribute table is
required beyond the NameID. Leave the assertion's other attributes empty unless you have a specific
reason to send more.
Make sure the email in the NameID exactly matches the managed account's email on the verified domain (case differences are usually fine, but a different address entirely will fail to match any account).
Step 5 — Enforce SSO with an authentication policy
Saving the SAML configuration does not turn SSO on by itself — Atlassian Guard enforces SSO through authentication policies, separate from the SAML setup.
Open authentication policies
admin.atlassian.com → Security → Authentication policies.
Assign the policy
Either edit the default policy or create a new one, then add the members/groups you want covered. Under the policy's SAML single sign-on setting, choose Required so members assigned to this policy must authenticate via MojoAuth — password login for those accounts is disabled.
Roll out gradually (recommended)
Start with a test policy applied to a small group (e.g. your admin team) before moving the organization's default policy to Required, so you can confirm SSO works before locking everyone out of password login.
Keep a break-glass path. Atlassian always allows the organization admin who configured SAML to authenticate outside of enforced SSO recovery flows, but you should still verify at least one admin account is excluded from the enforced policy (or knows the recovery process) before rolling SSO out broadly. Losing access to both MojoAuth and Atlassian admin at once locks you out.
Step 6 — Test
- IdP-initiated: on the MojoAuth connection page, click Test SSO. This runs an IdP-initiated
login and POSTs a signed assertion straight to Atlassian's ACS URL. A successful test lands you
signed in to
id.atlassian.com/ your Jira or Confluence site. - SP-initiated: open an incognito window, go to your Jira or Confluence site URL (or
id.atlassian.com), enter a managed-account email covered by the enforced policy. Atlassian redirects to MojoAuth's SSO URL; after authenticating, you're redirected back into the Atlassian product signed in. - Confirm SSO across products: since Guard SSO is organization-wide, a session established via Jira should also grant access to Confluence and Bitbucket on the same domain without a second login.
Troubleshooting
"This domain isn't verified" / SAML option missing The organization has no verified domain, or the domain used by the accounts you're testing isn't the verified one. Go to Directory → Domains, verify the domain (DNS TXT or HTML file), and confirm the test accounts show as managed, not just "linked."
"We couldn't verify your certificate" on Save
The pasted x509 certificate is malformed — usually a missing/truncated BEGIN/END CERTIFICATE line
or extra whitespace from copy-paste. Re-copy the PEM from MojoAuth's Copy PEM button (don't
hand-edit the downloaded .crt) and paste it as-is.
Users land on an Atlassian error after MojoAuth authenticates ("recipient does not match" / ACS
mismatch)
The ACS URL entered in the MojoAuth connection doesn't exactly match what Atlassian generated
(including the connection=saml-... query string). Re-open Security → SAML single sign-on in
Atlassian Guard, re-copy the exact SP Assertion Consumer Service URL, and update it in the MojoAuth
connection's SP details.
"Audience validation failed" The SP Entity ID in the MojoAuth connection doesn't match Atlassian's SP Entity ID (Audience URL) exactly. Copy it again from the same Atlassian screen — don't substitute your Jira site URL or a guessed value.
Users still see a password login prompt / SSO isn't enforced The SAML configuration was saved, but no authentication policy requires it for those users. Check Security → Authentication policies, confirm the affected users' group is assigned to a policy with SAML single sign-on set to Required, not just the default (unenforced) policy.
A specific user can't be forced into SSO Their account is unmanaged (personal email, or an email outside the verified domain). Only managed accounts can be placed under an enforced authentication policy — check Directory → Managed accounts and resolve the domain claim for that user first.
Locked out of Atlassian after enforcing SSO Use the account that configured Guard SSO, or an organization admin excluded from the enforced policy, to sign in and adjust the policy. As a last resort, Atlassian support can assist an organization admin in recovering access — this is why a break-glass admin (Step 5) matters.
Next steps
- Manage the connection — edit, rotate the certificate, or disable it later.
- SAML SSO Connections — the full concept doc for attribute mapping, NameID formats, and signing options.
- More guides: Integration Guides overview.