By Ryan Breen, Director of API Management at Cimpress

Amazon delivers standards-based API authentication & new mechanisms secure LocalStorage

We're about a decade into the microservices era and while we've come so far, there's still vast room for improvement. Most notably, there is still a paucity of tooling and practices to support companies who are delivering microservice APIs directly to customers. Take OAuth2 as an example. The only standard authorization mechanism provided today is Scopes, which are woefully inadequate for most microservices APIs, particularly those which need to manage access at the level of resources. This lack of standards makes authorization and access control a problem without a common solution, so everyone is left to either create their own standards or code to a vendor's design. In 2020, I expect we will see broader API delivery options for smoother customer experiences and more mechanisms to help secure APIs of all varieties.

Prediction: SaaS solutions will provide authorization and API delivery options for businesses who want to bring microservices APIs directly to their customers.

It's no surprise that Amazon, who builds each component of AWS as a microservice directly addressable by customers, is the closest solution I've found. You can write custom authorizers that take in OAuth bearer tokens and convert these into access decisions based on IAM policies. This is really slick stuff, but it does require a lot of configuration and customization on the part of the AWS customers. I think the market need is great enough that someday we'll see a standards-based, resource-aware API authentication and authorization product from Amazon delivered as a first-class, named product, not an orchestration tucked away in a tutorial.

Prediction: Browser vendors will start adding mechanisms to secure LocalStorage

The most common mechanism for securing APIs is OAuth2 with Bearer tokens in the form of JWTs.  When calling APIs from interactive sessions in a user's browser, the path of least resistance is to log the user in, stuff their JWT in the browser's LocalStorage, and go about your merry way calling APIs with that JWT.  There's just one problem: everyone says don't do that.  And they say this for good reason: anyone running JavaScript on a page can read any value out of LocalStorage, so if you treat it as a store for passwords (which, ultimately a JWT is), you're opening your customers up to trivially exploitable cross-site scripting attacks.  The recommendation is to, instead, use HTTP Cookies to convey this authentication information as 20 years of incremental security enhancements from the browser community have gradually buttressed Cookies from cross-site scripting and cross-site request forgery attacks.

There's a major problem with the recommendation to use Cookies, though.  Developers building microservices don't expect to handle Cookies: those are icky, legacy, browser-related implementation details that we all assume (until too late) have nothing to do with the API ecosystem.  We start off building an API with a clean little AWS API Gateway Custom Authorizer to validate a Bearer token.  We get our API all polished up in production for machine-to-machine calls, and that's in production for a few months creating shareholder value before someone decides they want to call an API from a browser.  Then, someone stumbles over an article telling them not to put JWTs in a browser, and you need to rearchitect everything to introduce Cookies into the mix.  And that's not an easy thing to do because Cookies are just a fundamentally alien technology to the OAuth flows most of us are building for, so you end up with this weird architectural special case for one particular audience of users.

At this point, many developers go hunting for an iconoclastic article telling them it really is okay to use LocalStorage rather than rebuild everything to use Cookies.  And lots of folks never found the articles telling them not to put JWTs in LocalStorage in the first place and are inherently insecure forever.

For all these reasons, I believe that in 2020 (or, at least, the 2020s) browser vendors will begin rolling out mitigations to help secure LocalStorage, adding in the moral equivalent of all the mechanisms Cookies have been gifted over the last 20 years.  Cookies started out with many of the same security vulnerability LocalStorage originally had, and only through bolt-ons like the Secure, HttpOnly, and SameSite flags have they acquired all the properties that make them a better choice than LocalStorage for JWTs.  There's no reason, other than time and energy, why LocalStorage couldn't be similarly secured by adding new mechanisms to declare which scripts should be allowed to read and write which values in the store.

##

About the Author

Ryan Breen is the Director of API Management at Cimpress, the parent company to Vistaprint and other leading mass customization businesses. Ryan has been at Cimpress for the last 5 years, helping advance the organization's shift to an internal platform built on microservices. Ryan is responsible for managing the API ecosystem as well as the documentation, training, and UX that unites the platform. Prior to Cimpress, Ryan was the Chief Architect at Everbridge, the world's leading mass notification service.