Evolution of authentications

Steve Mu
2 min readSep 21, 2022

--

In the beginning, a hidden iframe on a seemingly good page could make a request to a 3rd party website with our authentication cookie.

Then came the OAuth 2 approach. Authentication pass access token to client application with a callback in the URL. Then client app stores the token in the browser. This is insecure because other apps could read the browser storage.

Next is the Authorization code flow with PKCE. The server would pass a authorization code to the client application, then client app use the authorization code to request access token and store it in the browser. The access token is short-lived, just a few mintues.

The issue of refresh token. Since access token is short lived, a refresh token is used to get new access token, in the server side.

For client side application, to manage the refresh of token, a hidden iframe is rendered on the page that check the session with the authorization server by sending a cookie.

But soon this will stop work because browsers are going to stop supporting 3rd party cookies.

New best practice is to use a BFF. Use cookie for authentication with SameSite=Strict and a custom x-csrf=1 header. x-csrf is needed to prevent 3rd party site with iframe making request to our site, as those requests won’t come with x-csrf header; it is also needed for older browsers that don’t support SameSite cookie, which is vulnerable to this attack still.

--

--