Is there any supported way to give external Atlassian-account users an org-specific SSO-first login

[Yousif Hassan]

Hi,

I’m trying to understand whether this is just expected Atlassian Cloud behavior or whether there is a supported workaround.

Our setup:

• Atlassian Cloud org with Atlassian Guard
• Microsoft Entra ID as SAML IdP
• External user policy set to Single sign-on
• External test user has:
  • Jira Product Discovery -> Contributor
  • Jira Service Management -> Customer

Problem:
For external users (unclaimed domains), Atlassian keeps sending them to the generic login experience at id.atlassian.com/login, where they can see password/social/Microsoft/etc options.

If they click Microsoft, the flow seems to use Atlassian’s generic Microsoft login path, not a clean organisation-specific SAML-first route.

What I’m trying to achieve:

• External partner users should access JPD/JSM resources through a clean SSO-first route
• I do not want them landing on a generic Atlassian login page with lots of options
• I want something closer to an org-specific instance/login flow

What I want to know:

1. Is this generic login behavior expected for external Atlassian-account users?
2. Has anyone found a supported way to avoid the generic login page and force a cleaner org-specific SSO- first flow?
3. Is the answer basically “you only get that with managed accounts”?
4. Has anyone solved this with:
   1. portal-only customers
   2. a broker/IdP layer
   3. shadow managed identities
   4. some other pattern

I’m not asking about internal verified-domain users. Those work differently. I’m specifically asking about external Atlassian-account users who still need access to Jira/JPD/JSM.

If anyone has gotten this to work cleanly, I’d like to know what the actual supported pattern is.

[Andrea Robbins]

You’ve hit a current limitation in how Atlassian’s cloud login flow works rather than something you’ve misconfigured.

What you want vs what’s possible today

Your goal

• External partner users (unclaimed / external domains)

• Access JPD/JSM via a clean, org-specific, SSO‑first route

• Avoid the generic id.atlassian.com/login screen with:

  • password

  • social

  • “Continue with Microsoft”

  • etc.

• Have something that feels like a dedicated tenant login page.

What actually happens

• Even with:

  • SAML SSO configured,

  • Authentication policies enforced, and

  • External user security policy requiring SSO

• Unauthenticated users coming to your site still get sent to:

  • https://id.atlassian.com/login

• From there:

  • “Continue” follows the SAML/auth policy logic.

  • “Continue with Microsoft” uses Atlassian’s generic Microsoft OAuth flow, not your org-specific SAML config:

    • This is described here:
      What are the differences between "Continue with Microsoft" versus SAML SSO? | Atlassian Cloud | Atlassian Support

So your observation is spot on: external users are seeing the generic login gateway and can choose paths outside your clean SAML‑first route.

---

Is there a way to force an org‑specific SSO‑first flow?

For Atlassian Cloud today, there is no supported way to bypass the id.atlassian.com/login step and automatically redirect all unauthenticated users straight to your SAML IdP, even when SSO is enforced. This is tracked as a product suggestion:

• “Allow automatically redirected to SSO provider when logging into a site”
  https://jira.atlassian.com/browse/ACCESS-1609

  “Currently, when an SAML SSO is enabled for the instance, the user still need to key in their email in id.atlassian.com, then it will redirected to the SSO provider.”

  “It will be best if there's option to go automatically to the login from the configured SSO provider.”

  “Workaround: No workaround”

There’s a related request that asks for more control over the login workflow (similar spirit, more admin controls around SSO-first behavior):

• “Provide additional controls for SAML SSO login workflow”
  https://jira.atlassian.com/browse/ACCESS-1506

Both issues effectively confirm:

• The generic Atlassian login page is currently unavoidable as the first step.

• Atlassian does not yet provide:

  • a dedicated, org-branded login URL that always SAML‑redirects, or

  • a setting that hides non-SSO options for users (including external users).

---

About “Continue with Microsoft” vs your SAML policy

The doc below explains that “Continue with Microsoft” is a separate OAuth flow, not your core SAML SSO:

• “What are the differences between ‘Continue with Microsoft’ versus SAML SSO?”
  What are the differences between "Continue with Microsoft" versus SAML SSO? | Atlassian Cloud | Atlassian Support

Key points that match exactly what you’re seeing:

“Users have several options when logging into Atlassian Cloud…”

“If the user is part of an Authentication Policy with SAML SSO enforced and clicks on Continue:
– The user will be directed to your IdP (Azure AD) for authentication using SAML.”

“If the user is part of an Authentication Policy with SAML SSO enforced and clicks on continue with Microsoft:
– The user will be redirected to Azure AD to use their Microsoft Account for authentication.
– This process utilizes the OAuth2.0 protocol not SAML…”

So:

• “Continue” = goes via your configured SAML SSO for users under an enforced auth policy.

• “Continue with Microsoft” = a different Azure “Atlassian” app using OAuth, not your SAML flow; it may later match to your SAML identity, but it’s not the clean SAML‑first route you’re aiming for.

---

How this applies to external users

Your external users are controlled by an external user security policy:

• Available external user security policy settings
  Available external user security policy settings | Atlassian Support

This confirms you can enforce SSO for external domains, but it doesn’t change the front-door UX:

“You can require users to verify their identity with single sign-on.”

What it doesn’t provide is:

• A separate, org-specific login URL

• A way to skip or hide the generic id.atlassian.com options for those external users

So your current setup is “correct” from an access-control standpoint, but product limitations are blocking the UX you want.

---

Atlassian’s own docs/JAC tickets say there is no official workaround to completely avoid the generic login screen.

The best you can do (for now) is Train/guide external users to always use “Continue” (not “Continue with Microsoft”). This ensures they take the SAML route governed by your policy.

Additionally, If you use Microsoft Entra ID: consider blocking the generic OAuth application

• The article above notes you can restrict the “Atlassian” OAuth enterprise app by requiring assignment.

• That means if users click “Continue with Microsoft”, they’ll get blocked, nudging them back to “Continue” (SAML):
  

• This is discussed here:
  What are the differences between "Continue with Microsoft" versus SAML SSO? | Atlassian Cloud | Atlassian Support

*Full disclosure, I got Rovo to help me summarize the above, and I removed some of the sections/words & re-worded what it stated to make more sense, and I did read the documentation myself to confirm everything it stated. 

Sorry for such a long response, but hopefully this was helpful!

Andrea

[Andrea Robbins]

I'm reading into the comments of this support ticket: https://jira.atlassian.com/browse/ACCESS-1609 , and try if either of these work:

---

Marc Schildt added a comment - 10/Dec/2025 1:07 PM - edited

For me it worked fine to set ?email=<some random string>@<idp linked domain>.

My Landing URL is:
https://id.atlassian.com/login?email=takemetomyidp@my.domain.com

my.domain.com is linked to my idp https://support.atlassian.com/provisioning-users/docs/link-domains-to-identity-provider-directories

So all users with a matching mail domain (in my example above my.domain.com) get redirected to my idp.
The User may have to login or may have a active idp session session - they will send saml attributes like user id, name and mail provided from my IdP (thats why <some random string> is working).

---

Paul Estep added a comment - 21/Nov/2025 8:42 PM - edited

Just use this in the "Reply State" field in Azure (if you are using that)

https://id.atlassian.com/login?email=\{user.userprincipalname}&application=jira&continue=YOURCOMPANYNAME.atlassian.net/

replace YOURCOMPANYNAME with your custom URL for jira/Atlassian.

if {user.userprincipalname} does not work for you, you can use {user.mail} instead.

[Arkadiusz Wroblewski]

Hello @Yousif Hassan 

Even with Guard and an external user policy set to Single sign-on, they still go through the generic Atlassian login page first. The Continue with Microsoft option is a separate login path, not your org-specific SAML flow, so there is currently no supported way to force a clean SSO-first experience for that model.

At the very end, external User are external 🤠😅

It is a current platform limitation.

The only real alternatives are to use portal-only customers for JSM access, or published JPD views if they only need to see ideas. Once they need actual JPD access with Atlassian accounts, they are back in the normal Atlassian login flow.