Male hands on laptop login user authentication system SAML, Kerberos and OIDC

The difference between Kerberos, SAML og OpenID Connect (OIDC)

Simplify user authentication with Kerberos, SAML and OIDC. Find out how these protocols work, their benefits and best practices for implementation.


Many companies face a significant challenge with user authentication, especially as the number of systems increases. Providing secure access to all users can become overly complicated, as few administrators and consultants specialize in this area. Based on our support experience, we are aware that this topic can be confusing and overwhelming.

This article aims to introduce three commonly used authentication protocols, explain how they work, highlight their key benefits, and provide best practice examples.

Kerberos 

Integrated Windows Authentication / Kerberos gives the end-user access to Atlassian products without entering a username or password. It is typically used in an enterprise Local Area Network (LAN) and is the preferred choice for Windows domains and Microsoft Desktop environments.  

IWA / Kerberos requires that client machines have access to a Key Distribution Center (KDC), which in the Windows environment generally means Active Directory. For security reasons, AD is generally inaccessible outside the local network/corporate intranet, making Kerberos mainly applicable within a company network. 

SAML and OIDC 

Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are the most widely used federation protocols for web-based single sign-on, and Kantega SSO Enterprise supports both. These protocols are secure and work across remote networks and federate user identities across domains. They allow you to log in to your Atlassian Application through an identity provider service, such as AD FS, Azure AD, Google, Okta, AWS, Keycloak, and many more. 

To begin, what’s the difference Between OAuth, OpenID Connect, and SAML? 

It is important to note that OAuth 2.0 is an authorization framework, not an authentication protocol. OAuth 2.0 uses scopes for granular access and allows usage of back-channel communication from server-to-server in its authorization code flow, for exchanging information, which mitigates risk of sensitive data exposure on the user's browser.

OpenID Connect (OIDC) is an authentication protocol and an identity layer built on top of OAuth 2.0. It does everything OAuth does but adds identity verification and profile information on top of the authorization code flow. It uses JSON Web Tokens (JWT), and an authentication event will contain an ID token, to provide identity information of the user that logged in.  

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. In this scenario, 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 must authenticate, and if it is their first login, a consent screen is displayed, requesting permission to retrieve personal user data.  

Google Account Sign In form

Combine Kerberos with other SSO mechanisms 

It is perfectly fine to combine IWA with other SSO mechanisms such as SAML or OpenID Connect (OIDC). In such a combination, IWA provides hassle-free login experiences when the user is present at his desktop machine in the office, while SAML / OIDC enables the user to log in when they are on the go outside the office or when accessing from cellphones or other non-Kerberos compatible devices. 

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 

Tailored for use with Atlassian Jira, Confluence, Bitbucket and Bamboo, 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. 

References: 

Kerberos: https://www.rfc-editor.org/rfc/rfc4120

OAuth 2.0: https://www.ietf.org/rfc/rfc6749.txt

OIDC: https://openid.net/specs/openid-connect-core-1_0.html

SAML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html



Similar posts