Why you shouldn’t use access tokens in your front-end any more

And how to move authentication to the server-side

Albert Starreveld
4 min readMay 25


To obtain authorization for API-endpoints, many Single-Page Applications use OAuth2. Word has it, lately, you should not use access_tokens in the front-end any more. Why is that?

Read this article to learn:

  • How a Single Page Application obtains authorization at the client-side
  • How this may be a risk
  • What the alternative is

How modern web applications authenticate

Modern web applications authenticate users with Single Sign-On. Medium is a good example of this: You can log-in with your Google account, at Spotify you can log in with Facebook, and so forth.

This means the log-in page is not part of a modern web application anymore. This has some implications:

  • When you log-in, you are logged into Google, for example. When you log in with Google, they issue some sort of token which represents your session at Google.
  • When you want to log-in at, say Medium, you will have to leave Medium.com, navigate to Google to authenticate, and then navigate back to Medium.com.

This is schematically displayed in the following diagram:

How this used to be implemented in a SPA

Logging into an OAuth2 server manifests in an access_token. An access_token is an opaque string which represents a users authorization for a given period of time.

To obtain such a token, the user interacts with the authorization server. This is schematically displayed as follows:

As displayed in the diagram, the Single Page Application redirects the user to a special endpoint at the authorization server:




Albert Starreveld

Passionate about cloud native software development. Only by sharing knowledge and code we can take software development to the next level!