Backend-for-Frontend Auth: The Secure JS App Architecture

So when it comes to OAuth, many of the challenges that devs run into aren't actually the things they're expecting to have issues with. We worry about things like production issues and then end up struggling with token storage and 401 errors and cores.

Now, standards-based OAuth uses OAuth2 for authorization and OIDC for authentication. Both of these specifications use an authorization server to issue tokens. Now, let's compare OAuth in the back end and the front end. The back end can authenticate itself with the authorization server. It can persist user sessions and it can safely store tokens.

On the other hand, a front end app can't safely use a secret. It can't persist sessions, and it can't safely store tokens either. So these security issues are definitely not trivial. But if you control a back end that's serving your front end, you can get the security of back end OAuth in your front end.

So let's say you have a JavaScript front end, a code executing back end serving the front end, and a standards-based authorization server. The user loads the front end, which calls the back end OAuth API to check for an existing session. If they don't have a session, the back end creates a proof key for code exchange or PXE challenge. This means it creates random string called a code verifier and uses a code challenge method to hash the code verifier to create what we call the code challenge. The back end then sets an HTTP-only PXE cookie.

And when the user logs in, the front end calls the back end login endpoint. The back end composes an authorization request and redirects to the authorization server's authorized URI. And it includes the code challenge with this request. Now the auth server verifies the user's credentials and redirects to the back end callback route with the authorization code. The back end calls the auth server's token endpoint, and it includes the client secret, the code, and the code verifier.

And the auth server uses the code challenge method to create the code challenge and then match it to the one from the authorization request. If all this is successful, then the authorization server returns tokens. Now the back end can delete the PXE cookie and then create a session ID and store tokens. The session's time to live should match the refresh token expiration. Back end then sets a session ID cookie and redirects the front end to a login callback page.

Now whenever the front end app loads, it calls a back end check session endpoint with the session ID cookie if it exists. And the back end uses that session ID to look up the user's session. If there's a valid session, then the back end uses the access token expiration to schedule a refresh grant for when the token expires. If the access token is expired but the refresh token is valid, then we're going to perform a refresh grant by sending the refresh token to the auth server's token endpoint. The auth server sends new tokens down the wire, which are saved in the session.

Now when the app needs user data, it can call a user info endpoint with the session cookie. The back end looks up the session, and then it can either decode the ID token or it can call the authorization server's user info endpoint with the access token in the authorization header. The authorization server returns user info, which is stored in the user's session and then is sent to the front end. Now if the check session looks up the session ID and either the session is expired or there is no cookie, or the session just doesn't exist, then the user's not logged in and they must do so to proceed.