Is there any supported way to give external Atlassian-account users an org-specific SSO-first login
1 answer
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/loginscreen 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:
-
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:
-
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.comoptions 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
I'm reading into the comments of this support ticket: https://jira.atlassian.com/browse/ACCESS-1609 , and try if either of these work:
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).
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.