Enable single sign-on for your self-hosted Atlassian products and manage your users seamlessly and securely.
It’s the stuff of nightmares: the dreaded “Forgot your password?” odyssey after guessing the umpteenth variation of your workhorse password. New services, all requiring identity confirmation, are introduced every day, so it’s no wonder single sign-on (SSO) solutions have become critical for enterprise organizations.
But the need for SSO goes well beyond a seamless user experience. In fact, its most important function, perhaps, is ensuring security and compliance for enterprises that have to manage user access to the myriad apps deployed across the company.
Cue OpenID Connect (OIDC), a hyper-focused authentication layer on top of the OAuth 2.0 authorization framework and an emerging standard for SSO and identity provision. While still a relatively young technology, OIDC is rapidly growing in popularity, primarily because of its flexibility and usability. And now our Data Center editions of Jira Software, Jira Service Management, Confluence, and Bitbucket will include support for OIDC.
Supporting OIDC not only makes it easier to comply with security standards and requirements set by your organization, but provides an interoperable way, similar to REST, to incorporate secure identity management in a frictionless environment.
How OpenID Connect works, and why it matters
Teams are deploying more mission-critical software than ever before; they’re relying on chat tools for internal communications, and constantly context switching between dev tools and project management tools. As a result, the number of applications with access to sensitive information increases by the day. So ensuring a secure environment is at the top of any organization’s priority list. The matter is compounded for enterprise organizations overseeing a decentralized business, with a range of teams and tools spanning function, region, and even subsidiary. This commonly results in enterprises needing support for multiple authentication standards.
We have a lot of disparate services in our company that use different authentication sources, and I’d like to bring all of this together into a single source for ease of onboarding/offboarding […] If we had OIDC as an option in our Atlassian products, it would give us more flexibility in our spaghetti pile of services. – Financial Services customer
With an extended range of supported authentication options, enterprise customers have more flexibility to achieve single sign-on for users across the entire organization. As for OIDC in particular, it’s easy to integrate, and offers the features and security options to match and adapt to increasingly demanding enterprise requirements. And while there have been third-party plugins that provide workarounds to support OIDC in Atlassian products, their setup logistics and additional cost are not ideal. With support for OIDC, customers can simplify billing and streamline integration.
All of this is not to say that OIDC is the only authentication option out there, or the right one for your organization. There are a few other alternatives we see customers use, such as Crowd, which offers single sign-on/authentication for Atlassian products in addition to several other user management features (offered for both Server and Data Center deployments), and SAML, which we currently bundle with our Data Center products via plugin on the Marketplace. While nuanced, it’s important to understand the differences and similarities between SAML and OIDC.
Differences between the most common identity standards
As it stands today, there are three leading open standards for identity online: OIDC, OAuth 2.0, and SAML. While some may be well versed on what OIDC is and how it works, many still struggle to understand how it compares to other identity standards such as OAuth 2.0 or SAML, and understanding each is an important step towards protecting your organization’s data from the ground up.
- OpenID Connect OIDC is a simple identity layer on top of OAuth 2.0 framework that is used to verify user identities based on the authentication performed by the authorization server, and to gather basic user profile information. Have you ever visited a site you’d never interacted with and been given the option to log in with your Google credentials? This is OIDC in action. If you select the option to log in using Google, the site will contact Google’s authentication server to collect your pre-confirmed credentials. Once verified, Google’s server will spin up a JSON web token (think of it a virtual certificate of authenticity) and send it back to the initial site. The site then confirms the token and allows you access. Simply put, it’s a means to authenticate users with SSO by using a safe, self-contained token that transmits information between multiple parties.
- OAuth 2.0 Understanding authentication versus authorization is very important here. Authentication is the process of verifying oneself, whereas authorization is the process of verifying what you have access to. The most important thing to know about OAuth 2.0 (at least in terms of how it relates to OIDC) is that it is the authorization framework on which OIDC is layered, not an authentication protocol like OIDC or SAML.
- SAML On the surface, OIDC and SAML are quite similar. The biggest difference you’ll find in SAML is based on its explicit trust between the site (also known as the service provider) and the identity provider (IdP) – OIDC does not have such a requirement (hence its use of JSON tokens). Let’s say you want to log in to your corporate intranet to access additional services deployed by your organization, like Salesforce or Workday. SAML uses an XML-based standard for exchanging authentication and authorization data (and thus is independent from OAuth 2.0) between trusted IdPs and service providers to verify your identity and permissions. Since there is an existing, explicit trust between these services and your organization, your single login will give you access across the board.
How to get started with OpenID Connect
While support will be built into the Data Center editions of Jira Software, Jira Service Management, Confluence, and Bitbucket incrementally across coming releases, you can get started immediately by downloading our plugin, SSO for Atlassian Server and Data Center. With the plugin, you can delegate authentication to the OIDC or SAML identity provider of your choice to connect the aforementioned Atlassian Data Center products with your identity infrastructure.
If you’re interested in learning more about some of the other investments we’re making into the security and compliance space in addition to support for OIDC, be sure to register for our upcoming webinar.