APIs are the key to enabling applications to communicate, share information and work together. However, securing APIs and providing the best experiences to users, continue to challenge ISVs and software developers. Ryan Breen, Director of API Management at Cimpress, says in 2020, progress will be made toward new tools that can facilitate API authentication, authorization and security. Breen says to watch for these two advancements:
Prediction: SaaS solutions will provide authorization and API delivery options for businesses that want to bring microservices APIs directly to their customers.
Breen says, “It’s no surprise that Amazon, which 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,” he says.
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,” says Breen. “There’s just one problem: everyone says not to do that — and 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.”
Breen says it’s recommended, instead, to 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,” says Breen. “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,” he says. “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.”
Because cookies are alien technology to the OAuth flows that most developers are building for, Breen says, “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,” he says. “And many folks never find those articles 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,” Breen says. “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.” 
