SAML (SAML 1.0 and 2.0) and OpenID Connect (OIDC) are identity protocols, designed to authenticate users, and provide identity data for access control and as a communication method for a user’s identity. Either protocol may be the basis for Identity Providers (IdPs) that offer a range of user identity management and services and may be used for single sign-on (SSO) applications.

Mainly used for Enterprise and Government applications, SAML 2.0 is a mature technology dating from 2005 and supports a wide range of identity functionality. SAML uses XML for its identity data format and simple HTTP or SOAP for data transport mechanisms. The service requesting and receiving data from the IdP is known as the Relying Party (RP). The user identity data, encapsulated in an XML document called the SAML Assertion, is in the form of attributes, e.g., email address, name, phone, etc.

SAML can provide a mechanism for federated identity.

Before a service provider/Relying Party can interact with an IdP for user authentication, metadata must be exchanged between the RP and the IdP. These metadata, in XML format, specify endpoints, signing and encryption certificates, supported connection methods, attribute format, etc., that each side of the SAML binary must know about the other. Each party then uses the other’s metadata to configure their side of the system.

To authenticate a user, the RP makes an authentication request (SAML AuthnRequest) to the IdP, using either an HTTP form post (POST binding) or a redirect with query string (Redirect binding) to make the request. This request is normally signed by the RP.

The IdP then verifies the request, authenticates the user and returns a SAML Response, containing the SAML Assertion with the agreed attributes, to the RP in a form POST. Some IdPs support user consent of attribute release, but this is not part of the SAML protocol. Normally, SAML responses and assertions are digitally signed by the IdP; assertions may also be encrypted if the application considers HTTPS insufficient protection.

SAML supports a range of AuthnRequest options that allow dynamic behavior, e.g., acceptable user authentication methods, disabling SSO (forcing login to IdP), restriction of proxy IdPs, etc. Further custom options are also supported.

A relatively new protocol, continuously evolving, OIDC was designed with web and mobile applications in mind. Designed to be easy to adopt and use, OIDC is an extension of OAuth2, with data structures in JSON format (JWT), and simple HTTPS flows for transport. User identity data (“claims”) are issued in a JSON web token (ID Token). The claims will include a persistent identifier and user data defined by the requested scopes. Conventionally, this token is digitally signed, and may also be encrypted where required.

OIDC scopes are used to specify which possible claims or groups of claims may be returned by the IdP. Acceptable scope values, and exactly which claims they relate to, are dependent on the IdP. A number of common scopes and claims are defined in OIDC, such as profile, address, email, etc.

As an example, the scope profile will generally contain the user’s name and may include their picture, date of birth, and other personal data, depending on what data the IdP has and what it determines should be included.

Like SAML, before OIDC can be used, both the RP and the IdP must exchange some data. However, these data can be much simpler in OIDC. At a minimum, the RP obtains a client ID and secret from the IdP, agrees on potential scopes, and informs the IdP of a URL endpoint to return codes or tokens to.

Being based on OAuth 2.0, OIDC has a number of use cases, known as flows, that determine exactly how the RP and IdP interact. The simplest flow is the Implicit flow, where the RP redirects to the IdP with the client ID and desired scope values. After the user has authenticated and consented to share these data, the IdP returns the claims in the ID token by redirecting to the RP’s pre-set endpoint. More secure flows don’t involve sending the ID Token directly, and instead, involve returning a single-use code, which the RP exchanges for the token through a back-end POST. In addition to the ID token, an access token may also be issued, which may be used by the RP to authorize requests for user resources, covered by the scope.

SAML has a long track record of providing a secure means of identity data exchange, so it is trusted by many organizations. It is also very feature-rich, covering a wide range of identity requirements.

OIDC, being newer and evolving (especially in the European banking sector, with Open Banking), is still lagging behind SAML in terms of features. For example, dynamic specification of proxy IdPs is still not fully supported. However, for many applications where a simple requirement for basic identity data is required, particularly in the consumer space, OIDC is very attractive, as it is far easier to use than SAML, and doesn’t require the heavyweight XML handling that SAML does.

Currently, SAML is widely used for government citizen IDs and enterprise authentication. However, this is starting to change, with more modern systems including the requirement for OIDC in place of SAML. This is due to the perceived more lightweight data processing requirements in OIDC, using JSON tokens (ID token) in place of XML. OIDC is ideal for use with mobile apps and single-page web apps, where the use of SAML would be a struggle.

Keep reading at our Intro to IAM page to explore more topics around Identity and Access Management.