Goal 1 – SPA Review

Background

In the Final SPA Coding Key Points we completed our SPA and API Code Sample, so let’s have a review of the technology and our goals.

OAuth Standards

In our SPA Requirements, we had a big Implicit Flow concern around Token Renewal, since we wanted to use Short Lived Access Tokens.

However, OIDC Client and Okta provide us with a good solution, so we have no Blocking Issues in this area.

SPA Security Library

The OIDC Client library works very nicely and has been a great help, by doing the heavy lifting for us.

It has some known issues, but also an active community, so we are on a good path where we will get future improvements for free:

API Security Library

In our NodeJS Server, the OpenId-Client has also been useful, and reduces the number of lines of code we need to write.

Note that an alternative SPA security option is to have a small server side and to implement the Authorization Code Flow for Server Side Apps. If using this approach with NodeJS then the above library is a great choice.

Okta Authorization Server

Okta is a Standards Based Authorization Server, and plays very nicely with the SPA and API security libraries we have chosen. We have not found any blocking issues yet with Okta.

I have also tested the code samples on Ping Federate and found no blocking issues, so our API and SPA code seems portable.

Other Authorization Servers?

We will shortly also run our sample against Azure Active Directory, and later against Google’s Authorization Server, to see how well it works with large vendor options.

Code Simplicity

I am pleased with the way our code turned out. I was able to meet my Coding Goals of being Modular, Technically Simple, Business Focused and Reliable, and the Javascript technology is a lot better than I expected:

We needed to write some simple plumbing in order to implement Reliable API Calls and to provide Supportable Errors. In a real application, we would now forget about OAuth and focus on growing the business logic.

Web Performance

We can easily move our SPA hosting to a Content Delivery Network, which was one of our big goals.

Our bundle sizes are bigger than we’d like after I have produced minified versions via ‘npm run build’. This is not ideal, but we can live with it:

I would expect this to be reduced over time though, perhaps partly as a result of crypto support being added to modern browsers:

Security Reviews and PEN Tests

We are using the Recommended OAuth Flow for an SPA, it uses Short Lived Access Tokens and is not subject to Cookie Vulnerabilities. We therefore expect our SPA to perform well in this area.

Least Privilege Issue

One Implicit Flow security issue I can think of is that we do not have the ability to use different access tokens with different privileges.

In the Authorization Code Flow, the user can log in and get a Refresh Token containing all privileges needed for the User Session:

The UI can then get Access Tokens with different privileges, and could use a Low Privilege for most operations:

This is an awkward coding model, and it is probably true that most Web UIs which use Access Tokens today are not coded like this. Instead it is most common for a UI to use same token for all CRUD operations.

For now I do not consider this a blocking issue or one that makes a major difference to security, but it is worth being aware of it as a limitation.

Authentication Strategies

If in future we need to make code changes in order to support a different vendor, we can do so by changing just our Authenticator classes. No changes are needed to other areas, such as the below HttpClient class.

Where Are We?

Our SPA and API solution has all essential End User features and it has not been too difficult from a coding viewpoint, since we made good technical choices. 

Next Steps