SAML on the Rebound

Using SAML Federation as an alternative to the OAuth 2 SAML Extension Grant

We were recently approached by a client to develop an API management solution which would allow distinct user communities to authenticate against their chosen identity provider, some of which would support the OIDC standard while others would rely on the SAML standard.

Our first thought was that this could be achieved via the OAuth 2 standard by having the client application first authenticate to the appropriate IdP.

In the case of the OIDC standard, an access token would be delivered upon completion of the login process, which could then be used as proof of authorization for REST API calls.

In the case of the SAML standard, upon receipt of the SAML Response from the IdP, the application could use the OAuth 2 SAML Extension Grant in order to exchange the SAML token for an access token which would then be used to authorize REST API requests.

For those unfamiliar with the OAuth 2 SAML Extension Grant Flow, here is a sequence diagram outlining how it works:

The first complication with this idea comes from the fact that the client application is an SPA, a Single Page Application running entirely within the user’s browser and with no backend, and the realization that the SAML Extension Grant requires the caller to present both a client ID and a client secret in order to make the exchange. With no way to securely store the client secret, we were left contemplating either a change to the architecture to add a backend, or being forced to accept that the security of this solution would rely on the inability of a malicious third party to steal or forge an acceptable SAML Response token from the IdP in order to move forward with this solution.