Please consider the envrionment before printing
SAML works really well for server-side applications, providing single sign-on across your applications. But can you use SAML with modern application types such as SPAs and mobile apps?
Although the world is slowly moving on from SAML, OAuth 2.0 and OIDC are only just in the process of addressing the requirements of large organizations who have their own custom SAML profiles, such as educational and government institutions. As these technologies coexist, it’s essential to discuss the applicability of SAML for modern application types.
This article covers the limitations of using SAML with Single Page Applications (SPAs) and mobile apps. We’ll share our best practice recommendations and a solution for integrating new application types into your existing SSO solution.
Browser-based applications such as SPAs, and native applications such as mobile apps, are prevalent today in ways that SAML could not anticipate in the early 2000s. SAML only provides a web browser SSO profile for web applications that have a server backend. There is no interoperability profile to support these modern application types. Consequently, you may face compatibility and security issues when using SAML with SPAs and mobile apps.
The SAML specification recommends digitally signing all messages based on a public/private key pair to ensure the integrity of the messages exchanged between a Service Provider (SP) and an Identity Provider (IdP). Signing is great if you can store your private keys in a secured web server backend. But how can you keep your keys safe in code running on someone else’s machine?
A secret is hardly a secret if it gets installed on thousands of mobile devices or is embedded in the JavaScript of a SPA. It is trivial for an attacker to decompile a mobile app or inspect source code in the browser. Your keys are unsafe and untrustworthy if you don’t own and secure the device. While a secret adds an extra step for an attacker, it cannot be trusted by the identity provider in the same way as a secret from a server-side client can.
Digitally signed SAML requests from an SP allow the IdP to verify that the requests are authentic and untampered. No other viable mechanisms are available to cryptographically bind requests to a specific SP. The more secure SAML flows use back-channel communication using HTTP Artifact Binding, which is out of the question for SPAs and mobile apps. Besides, the Artifact Binding uses SOAP, which we tend not to use these days.
SAML doesn’t offer any workarounds like the OAuth Dynamic Client Registration or Proof Key for Code Exchange (PKCE). There are workarounds such as intercepting messages using a proxy fronting the SPA. But these have been found to have various security vulnerabilities. Instead, we recommend sticking with trusted and established standards.
A mobile app is a package that sits outside of the web. Unlike a website, a mobile app can't receive back-channel or post requests. SAML requires the sign-on response to be redirected to the Service Provider using HTTP POST or HTTP Artifact. HTTP Redirect is not recommended as the SAML responses can get too large and exceed the URL maximum length. You can find messy and cumbersome workarounds suggested online, such as embedded web view, scraping the HTML page, using a proxy server that receives HTTP POST, and virtual private networks. But again, these have their security and usability limitations, and we do not recommend them.
Modern applications make heavy use of HTTP APIs. These APIs need to be protected, which is where delegated authorization becomes crucial.
SAML supports “delegation” by allowing an IdP to forward assertions to another IdP that it trusts. The user must own an identity with both IdPs. There’s a major problem here. The assertion token is used by an entity that it was not issued for. So, the SAML delegation flow is more of an impersonation than delegation. There is also no concept of limited granted access, which is imperative for flexible delegation.
On the other hand, OAuth was designed for delegated access to HTTP APIs. Although OAuth is an authorization framework, OIDC provides an authentication layer on top to match SAML’s identity layer. Unlike SAML, these protocols are designed for API protection and HTTP.
OAuth provides an extension grant type (RFC 7522), which allows a SAML assertion to be swapped for an access token so that it can call APIs on the user’s behalf. But this grant type requires SAML authentication to have taken place in the first place, and as we have discussed, SAML is not a viable solution for these application types.
Furthermore, contemporary providers that offer identity delegation use OAuth and OIDC, including Microsoft and Google. This means that you may not be able to integrate with them.
As many vendors are moving over to using OAuth and OIDC, you may experience compatibility issues when federating with an external identity provider if SAML is your only authentication protocol.
SAML is an XML-based markup language. It relies on an exchange of messages to authenticate in XML format. Over the years, XML has proven not to be the best format for security constructs, as it is a large standard with many obscure features and verbose syntax. Most of the successful attacks against SAML implementations have been due to XML processing vulnerabilities. These attacks range from privilege escalation to denial-of-service attacks.
A SAML Service Provider needs to share its configuration data with the partner IdP. A server-side web application can advertise its metadata at a chosen URI path, allowing the partner IdP to automate the retrieval of the configuration data on start-up. However, a mobile app can't advertise its metadata configuration. So, you will have to resort to file-sharing or manual configuration.
SAML was simply not designed for modern application types, such as SPAs and mobile apps. You'll spend time fighting the protocol and still end up with a solution that is cumbersome and has security holes. Instead, we recommend using OpenID Connect in SPAs and mobile applications. This protocol was designed with these application types in mind and works alongside OAuth 2.0, allowing for API authorization. It provides a simpler and standardized solution that overcomes shortcomings and messy workarounds required with SAML when using these application types.
But what if your organization has an existing SAML SSO solution or you want to federate with an external SAML identity provider?
Why limit yourself to one technology stack?
Using an OpenID Connect Provider such as Duende IdentityServer and IdentityServer4, you can use both OIDC and our SAML component to implement cross-protocol SSO. We provide both SAML Service Provider and SAML Identity Provider implementations, allowing you to implement either side of the SSO solution with ease.
As an identity provider, you can support cross-protocol SSO by allowing some applications to authenticate using SAML and others using OpenID connect. The user gets a single sign-on experience as both protocols use the same SSO session. This means that you can authenticate users regardless of the requesting application type and support applications that use SAML.
As a service provider, you can support many identity providers that use different protocols.
You can also combine the two approaches and act as both SAML SP and IdP while supporting other protocols such as OpenID Connect and OAuth.
SAML was simply not designed for modern application types, such as SPAs and mobile apps. Instead of fighting the protocol, we recommend using OAuth 2.0 and OIDC for these application types. That said, you need not restrict yourself to one technology stack. A cross-protocol SSO solution can enable you to implement best security practices while integrating with existing SAML SSO solutions. It allows you to authenticate users regardless of the requesting application type and support applications that use SAML.
Here are a few helpful links to get you started with OAuth and OIDC:
Check out our SAML component page for more information.
IdentityServer
