Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Bypass Okta (SSO) authentication for local or service accounts

Currently in the process of setting up Okta (SSO) with Atlassian Access for our Jira and Confluence (Cloud) tenants. 

We have a number of local or service accounts that are users in our Atlassian tenant however these accounts are not in Okta therefore we need to configure a separate authentication workflow for these accounts so that they authenticate against Atlassian instead of Okta.

I have read and looked into Atlassian Authentication Policies and I am able to set up a policy for the local, non-SSO users, as well as a policy for IdP/Okta SSO users.

Is my below understanding correct?

If I create an authentication policy for Okta SSO users, these users will be forced to login via SSO if SSO is enforced as long as these users email addresses/usernames have the same domain as the SSO integration (ex:

If I create an authentication policy for local / service account users, which are user accounts that reside only in Atlassian, and not in Okta, and if I add these users, regardless of their username / email address domain (ex: to this authentication policy, will they bypass the SSO authentication workflow?

If I link as my Identity Provider (Okta) in Atlassian, will this affect how the authentication policies work? Or will the authentication policy have priority over the Identity Provider being linked to and therefore I can control the authentication flow from the authentication policies?

Basically I want to ensure that even though I have the Identity Provider with Okta linked to in Atlassian, that I can still bypass the SSO requirement for accounts that have the domain in their username/email via Atlassian Authentication Policies so that they login directly to Atlassian instead of Okta.

1 answer

1 vote
Dave Meyer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Oct 24, 2022

Hi @Quentin Roberts ,

You have it correct. When you verify a domain ("") all Atlassian accounts with an email address on that domain become Managed accounts (this is true regardless of whether there's a corresponding account in verify ownership of your domain before we know anything about your identity provider.)

Authentication policies allow you to set up SSO with an IdP for a subset of your managed accounts, but place other accounts in an authentication policy that does not enforce SSO. Which is exactly what you want in this case.



Thanks for the quick response @Dave Meyer , much appreciated.

When I am able to get a maintenance window to test out the Okta SSO rollout I will attempt this and reply here if I run into any issues.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events