Security Assertion Markup Language (SAML) and OpenID Connect are the most widely used federation protocols for web-based single sign-on, and Kantega SSO Enterprise supports both. Both protocols are secure and work across remote networks. They allow you to log in to your Atlassian Application through an identity provider service, such as AD FS, Entra ID, Google, Okta, AWS, Keycloak, and many more.
First, -What’s the Difference Between OAuth, OpenID Connect, and SAML?
The first thing to understand is that OAuth 2.0 is an authorization framework, not an authentication protocol.
OpenID Connect (OIDC) is an authentication protocol and an identity layer built on top of OAuth 2.0. It does everything OAuth does. Plus authentication. It uses JSON Web Tokens (JWT), called an ID token, to provide authentication information.
SAML is independent of OAuth, relying on an exchange of messages to authenticate in XML SAML format, as opposed to JWT. Even though OpenID is a modern alternative to SAML, SAML is still the most common choice for SSO for most enterprise applications.
The table below summarizes the differences between SAML and OIDC:
SAML | OpenID Connect | |
---|---|---|
Message format | XML | JSON |
API | SOAP | REST |
Website authentication | ✅ | ✅ |
Mobile applications | ✅ | |
User consent | ✅ |
SAML relies on browser redirects, which does not work well in native mobile apps. However, note that many mobile apps, including the Jira Server Mobile and Confluence Server Mobile apps, are built using embedded web views. Here, SAML will work perfectly fine.
Because OIDC is a layer placed upon the OAuth framework, OpenID Connect can provide a built-in layer of authorization, which prompts a user to first consent to what the service provider can access. The login screenshots below show how such user consent is requested. First, the user has to authenticate, and if it is their first login, a consent screen is displayed, requesting permission to retrieve personal user data.
Multi-factor Authentication (MFA)
Both SAML and OIDC providers can be configured to make use of Multi-factor Authentication (MFA). More info about how to set up an identity provider in Kantega SSO Enterprise and enforce MFA.
Combining multiple authentication mechanisms
Kantega SSO Enterprise allows you to set up multiple identity providers concurrently and use SAML and OIDC in combination with other authentication mechanisms such as Kerberos and traditional username/password logins. More info about how to configure multiple authentication mechanisms and automatically route users based on user directory, group, and domain associations.
Illustrations
Kantega SSO integrates Atlassian systems with Identity Providers using SAML/OIDC technology
OIDC login flow
I image below, Kantega SSO secures the Web App which is Atlassian products and Azure AD is the Identity Provider.
This illustration and more details here:
https://learn.microsoft.com/en-us/entra/architecture/auth-oidc