Release of Kantega SSO Enterprise v.4.1.0 with support for API Tokens. This allow remote agents to establish personalized integrations with Atlassian...
OpenID Connect Explained
A brief introduction to OpenID Connect - the industry standard SSO protocol for online authentication.
OpenID Connect (OIDC) is a widely adopted single sign-on protocol used to offer secure logins on the internet. If you've seen the good old "Log in with Google" and "Log in with Facebook" prompts while signing up for web services, they are most likely running OIDC under the hood. OpenID Connect is also used to achieve single sign-on (SSO) in business-to-business software, so that employees easily and securely can access all their work apps.
Through OpenID Connect, it is possible to delegate authentication of users from the application itself, to an Identity Provider like Microsoft login, Google login, Okta or the company's own login portal. OpenID Connect is a federated SSO protocol allowing authentication across domains, and enables the user to enter the same digital identity for all the systems they use.
Keep on reading to get a birds-eye view of how OpenID Connect works, presented in an accessible way without too much fuss. For those who are interested, we recommend taking a look at the websites of the OpenID Foundation for more details about the standard.
The OpenID Connect login flow
The entire login process is illustrated by a flow where we imagine an organization using OpenID Connect as the SSO protocol to access their work applications.
Our scenario involves three actors:
- User: The person/employee attempting to log in.
- Work Application: Any of the user's applications used in day-to-day work, which the user is logging in to. This can be anything from project management systems like Jira and Confluence to the timesheet system, chat system, HR system or the system used to share documents and presentations.
- Identity Provider (IDP): A database of users that is used by an organization to manage access to all their software. This could typically hold the work email identity that employees use to access every application used in the organization. Examples: Azure AD, Google Workspace, Okta, OneLogin, Ping Federate.
The login process in OpenID Connect goes as follows, with six steps:
A user wants to access some content in a Work Application, and needs to authenticate.
The user is redirected to the Identity Provider and is presented with a login prompt.
The user authenticates by providing a username (e. g. work email), password, and optionally (but hopefully) a code from SMS or an authenticator app.
The Identity Provider then issues a functional permission slip called an authorization code. Next, the user is sent back to the application with the authorization code. The application can then use this to communicate securely with the Identity Provider about the user's login attempts and other user information.
Using the permission slip, the application can ask the Identity Provider for more data about the user's login attempts. This allows the application to ascertain that the user hasn't faked their login process, and can obtain the Identity Provider's verified information about the user's identity information like name, email, roles and more.
The user is authenticated, and can now use the application and carry out their work. Since they now have a session with the Identity Provider, they not only get access to the chat application, but any application using OIDC which gives instant access since their identity is live.
This makes work-life much easier, and the user can keep their focus on the tasks at hand.
Below is the entire process summarized in one figure:
Single sign-on offers a significant advantage over "traditional" username/password login in terms of both security and user experience. With SSO, an organization's users can apply the same digital identity to access all their work stuff, and do not have to deal with a large number of usernames and passwords. The password and access management is streamlined improving security, and users only have to get familiar with one type of login.
When compared to other protocols for single sign-on, OpenID Connect has achieved a high degree of specification-compliance throughout the industry, meaning much of its functionality can be used without a vast arsenal of vendor-specific band-aids. Its relative technical simplicity, thanks to being built on existing and well-established standards such as HTTPS and OAuth 2.0, offers both deep and wide technical capacities while simultaneously providing an advantage in terms of practical security.
OpenID Connect is an excellent technology to use for organizations that want to achieve the ultimate SSO experience, in the cross-section of security and ease-of-use. Read more about how Kantega Single Sign-on uses OpenID Connect to offer single sign-on in the Atlassian Ecosystem.