Single Sign On (SSO) solution/architecture for Single Page App (SPA)

Question

I've been investigating SSO solution for SPAs for some time. There're a lot of solutions with subtle difference, while I also found not really everyone has the same understanding of SSO and not many established pattern of SSO for SPA are out there. Thus I'm not asking for a detailed design/architecture, but just try to see if there's any common practice on this topic.

What do I mean for SSO?

1. We have a few new SPAs under development(also potentially mobile and tablet apps), which will be deployed in different servers and have different domains.
2. We also have a central IdP (authServer) where all the user identify will be stored.
3. Once I log into SPA1 and clicked a button which brings me to SPA2(or SPA3, SPA4, potentially), I don't have to enter user credentials and will be logged in automatically.

What's the difference for SPA? (as opposed to regular web app)

I've looked at a few solutions, even old solutions like SAML(just want to get a sense about SSO..). my current candidate is OpenId Connect, but then I realized a difference for SPA, if my understanding is correct: Unlike regular web apps, SPA usually doesn't have (or we try not to have) a backend server. What SPA has is just a server serving static pages along with scripts, style sheets, and images.

Now comes the problem:

OpenId Connect is based on OAuth2 Authorization Code grant type, which means either:

1. I need a backend proxy-like module for each SPA if I want to make it work.
2. I use a different solution to do client-side SSO, such as the one auth0 provides
3. I haven't found any other solution/examples

My question:

For above point 1, is my understanding correct ? Is it better not to let SPA have backend code like a regular web app?

For above point2, that sounds like a solution, but how is that essentially different than OAuth2 Implicit grant type ?

And, are there other solutions(framework, protocol etc.) that I should know but haven't explored yet ?

Outdated

By scripts, do you mean server, client or both sides? I'd imagine many a SPA could use jQuery to make calls to a back-end server through AJAX but maybe I'm missing something here. – Correggio

@JBKing You're definitely right. Scripts mostly means javascript, and it can make AJAX calls to back-end server, but not necessary to the same server i image,e.g. it can get order list by making calls to order service while get product details by calling product service. Order service and product service can be microservices and deployed on entirely different servers. – Outdated

Did you find any solution for this? – Oden

Answer 1

In addition to the Basic Client Profile that uses the Authorization Code grant, OpenID Connect has an Implicit Client Profile that builds on the Implict grant from OAuth 2.0. This profile allows for tokens to be delivered directly to in-browser/Javascript clients without involving a backend.

Murcia

Thank you very much ! So If I go this approach, then I guess I also need to enable CORS (since my Auth server and other backend service servers can be in different domains). Do you see any security concerns there ? – Outdated

Answer 2

Nowaday, the Code Flow, in combination with Cross-Origin Resource Sharing (CORS) and Proof Key of Code Exchange (PKCE), can also be used for Single Page Applications.

The "OAuth 2.0 for Browser-Based Apps"-Draft describes in detail the current steps you should use to implement OAuth/OpenID Connect for SPAs in a secure way. In Sec. 4, "Overview" the current best practice is summaized:

In recent years, widespread adoption of Cross-Origin Resource Sharing (CORS), which enables exceptions to the same-origin policy, allows browser-based apps to use the OAuth 2.0 authorization code flow and make a POST request to exchange the authorization code for an access token at the token endpoint. In this flow, the access token is never exposed in the less secure front-channel. Furthermore, adding PKCE to the flow ensures that even if an authorization code is intercepted, it is unusable by an attacker.

For this reason, and from other lessons learned, the current best practice for browser-based applications is to use the OAuth 2.0 authorization code flow with PKCE.

The draft resumes the following key points, you shoud take into account when implementing OAuth/OpenID for SPAs (or other public clients):

Browser-based applications:

• MUST use the OAuth 2.0 authorization code flow with the PKCE extension when obtaining an access token

• MUST Protect themselves against CSRF attacks by either:

  • ensuring the authorization server supports PKCE, or

  • by using the OAuth 2.0 "state" parameter or the OpenID Connect "nonce" parameter to carry one-time use CSRF tokens

• MUST Register one or more redirect URIs, and use only exact registered redirect URIs in authorization requests

Speak

Could you explain it a bit more, please? – Shrewd

Hi @SlavaFominII, I tried to give some more detail and cited the relevant parts from the RCF. Let me know if you have further questions or suggestions how I could improve my answer :) – Speak

Thanks, that's a great summary. – Shrewd