Why you shouldn’t use access tokens in your front-end any more
And how to move authentication to the server-side
--
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:
