SAML 2.0 has been an OASIS standard since 2005 and has been widely used since then by companies wishing to provide Single sign-on (SSO) to their user base, allowing access to multiple services through the use of a single login credential, thus improving the end-user experience.
SAML provides a way to authenticate users to web applications (known as Service providers (SPs)) by redirecting the user’s browser to the login page of an Identity Provider (IdP), then redirecting the user’s browser back to the SP with an XML token (the SAML assertion) containing details of the authenticated user and any permissions held by that user and stored by the IdP. The SP can extract the user’s details and permissions from the assertion and can decide the level of access to be provided to the user accordingly. Where multiple SPs are registered with the same IdP, a user can access many SP applications using a single credential (usually username and password).
Service Providers need to know the IdPs that they trust to generate a suitable SAML Request message and to send it to the appropriate URL. Similarly, IdPs need to know the SPs that trust them to assert their users’ identities to generate a SAML assertion targeted at the SP and containing the required user attributes.
Using SAML is ideal when integrating with existing SAAS applications or legacy systems that already use SAML for SSO. However, despite its widespread adoption over the last 15 years, there are limitations to SAML. It was not built with mobile single sign-on in mind, and as a result, workarounds are required to read the SAML token to ensure a coherent user experience is delivered. The XML assertion token is heavyweight when compared to a JWT (JSON Web Token), which is used by the OIDC protocol. Lighter weight data processing requirements are important for mobile and single page applications; in these scenarios, SAML would not be the optimal choice.
OpenID Connect (OIDC) is an alternative protocol to SAML; introduced in 2014 it benefits from a larger set of available libraries for integration with modern technologies. OIDC is much better suited for mobile and single page applications due to less demanding data requirements which translates to a faster end-user experience.
When onboarding the SP to an IdP, SAML requires endpoint details and two-way certificate exchange. Whereas OIDC allows for dynamic retrieval of IdP endpoints and certificates via a separate metadata endpoint. OIDC also offers refresh tokens and use of back channels for token delivery to support long-running transactions whereas SAML does not.
Whilst the SAML protocol is a trusted and secure method to manage SSO; it is important to recognise its limitations. Condatis can work with you to help you choose the best protocol for your solution.
Modernising your systems with OpenID Connect
As well as using your SAML system as-is, you may be planning to develop new OpenID Connect (OIDC) services. We can help organisations on that particular journey by integrating OIDC services with the same centralised identity management system using the Microsoft Azure AD B2C platform, allowing us to have the same user base through the use of the same login credential. This provides a seamless user experience whilst allowing the organisation to focus on its core business.
Condatis provides a migration path for organisations transitioning from SAML to OIDC over time while also continuing to support legacy services and protecting your past investments.