Skip to main content
Information Security

Return to Question

Notice removed Canonical answer required by mrksbnch
Bounty Ended with Sibwara's answer chosen by mrksbnch
Notice added Canonical answer required by mrksbnch
Bounty Started worth 100 reputation by mrksbnch
Formatting
Source Link
mrksbnch
mrksbnch
  • 13
  • 6

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

  1. Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case?
  2. Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes?
  3. Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains.
  4. Is the refresh token approach better / safer than the silent authentication approach?

1.) The user logs in (Authorisation Code Grant with PKCE): The login prompt/page is shown in a popup (or new tab) and the communication (authorisation code) is done through postMessage. 2.) The background script receives the authorisation code and exchanges it for an access token and rotating refresh token (which is probably necessary in this flow (?)) using the code and a code verifier. These tokens can then be saved in Chrome storage. We can potentially also encrypt the tokens but I’m not sure if that offers any additional protection (?) considering that the background script is not the same as a server. 3.) If the Chrome extension wants to receive data from the API server, it sends a message to the background script which will then send the API request using the tokens saved in Chrome storage.

  1. The user logs in (Authorisation Code Grant with PKCE): The login prompt/page is shown in a popup (or new tab) and the communication (authorisation code) is done through postMessage.
  2. The background script receives the authorisation code and exchanges it for an access token and rotating refresh token (which is probably necessary in this flow (?)) using the code and a code verifier. These tokens can then be saved in Chrome storage. We can potentially also encrypt the tokens but I’m not sure if that offers any additional protection (?) considering that the background script is not the same as a server.
  3. If the Chrome extension wants to receive data from the API server, it sends a message to the background script which will then send the API request using the tokens saved in Chrome storage.

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

1.) The user logs in (Authorisation Code Grant with PKCE): The login prompt/page is shown in a popup (or new tab) and the communication (authorisation code) is done through postMessage. 2.) The background script receives the authorisation code and exchanges it for an access token and rotating refresh token (which is probably necessary in this flow (?)) using the code and a code verifier. These tokens can then be saved in Chrome storage. We can potentially also encrypt the tokens but I’m not sure if that offers any additional protection (?) considering that the background script is not the same as a server. 3.) If the Chrome extension wants to receive data from the API server, it sends a message to the background script which will then send the API request using the tokens saved in Chrome storage.

While this sounds good and feasible in theory, we are wondering about the following points:

  1. Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case?
  2. Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes?
  3. Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains.
  4. Is the refresh token approach better / safer than the silent authentication approach?
  1. The user logs in (Authorisation Code Grant with PKCE): The login prompt/page is shown in a popup (or new tab) and the communication (authorisation code) is done through postMessage.
  2. The background script receives the authorisation code and exchanges it for an access token and rotating refresh token (which is probably necessary in this flow (?)) using the code and a code verifier. These tokens can then be saved in Chrome storage. We can potentially also encrypt the tokens but I’m not sure if that offers any additional protection (?) considering that the background script is not the same as a server.
  3. If the Chrome extension wants to receive data from the API server, it sends a message to the background script which will then send the API request using the tokens saved in Chrome storage.
Added question about potential CSRF vulnerability
Source Link
mrksbnch
mrksbnch
  • 13
  • 6

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? Is CSRF possible for these Next.js API routes? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

Source Link
mrksbnch
mrksbnch
  • 13
  • 6

Authentication in Next.js application (SSR SPA with long sessions)

We’re currently developing a Next.js application (server side rendering) and are looking for secure ways to keep the users logged in for longer periods of time.

AFAIK this can either be done using silent authentication or refresh tokens. General note: When a user is not logged in yet, we can redirect the user to a login page. If the user enters their credentials, we use the Authorisation Code Grant (to my knowledge PKCE is not needed in this case as it’s all server side during these steps) that will redirect back and respond with an authorisation code. We can then exchange this authorisation code with an access token (and refresh token) using a client secret (all server side).

Refresh Tokens

Since any client side storage (local storage, cookies, etc.) is not safe (XSS attacks) for storing any kind of tokens (especially refresh tokens), we are wondering if it’s generally safe to store a refresh token (and access token) in a HTTP only cookie considering that…

  • … the token values are encrypted, e.g. AES, with a secret that is not exposed to the client side.
  • … the refresh tokens are rotating, so when you retrieve a new access token with your refresh token, you also receive a new refresh token. The old refresh token is invalidated and if used again, all refresh tokens are invalidated.
  • … the refresh token automatically expires after a couple of days, e.g. 7 days.

Silent Authentication

A possible alternative could be silent authentication via an auth request on the server side (prompt=none). The auth session for the silent authentication would also be stored in a HTTP only cookie.

—

In both scenarios, it’s probably necessary to make sure that the client doesn’t know about any of these tokens (You could potentially use silent authentication on the client side using an iframe (the domain is the same, just different subdomains) but the client would then potentially receive a new access tokens which has to be stored in memory (potential XSS vulnerability)).

Since it’s a server side rendered SPA, the client side still needs to be able to get new data from the API server using the access token. For this, we were thinking of using Next.js API routes as a proxy: So, if the client wants to get new data, it will send an AJAX request to the respective Next.js API route. The controller for this Next.js API route is able to read and decrypt the HTTP only cookie and can therefore send the request to the API server with a valid access token in the HTTP header. Just before the short lived access token expired, the controller would need to first send a request to the auth server to retrieve a new access (and refresh) token and then continue sending the request with the new access token to the API server.

While this sounds good and feasible in theory, we are wondering about the following points: 1.) Is it generally safe to save a (rotating) refresh and access token in a HTTP only cookie? Does the cookie value need to be encrypted or is that unnecessary? Does a rotating refresh token offer any additional security in this case? 2.) Is the “Next.js API route as a proxy” method a secure way to make sure that the client side can get new data from the API server? If e.g. otherdomain.com would try to send a request to the (“unprotected”) Next.js API route, it would not respond with any data as it’s a different domain and the HTTP only cookies therefore not accessible, correct? 3.) Is it safe if the HTTP only cookie for the refresh token is shared across all subdomains and not tied to one specific subdomain (application)? This would allow us to access the cookie from e.g. the actual website or other subdomains. 4.) Is the refresh token approach better / safer than the silent authentication approach?

Follow-Up question: Can the refresh token approach also be used the authenticate users in a browser extension? So:

1.) The user logs in (Authorisation Code Grant with PKCE): The login prompt/page is shown in a popup (or new tab) and the communication (authorisation code) is done through postMessage. 2.) The background script receives the authorisation code and exchanges it for an access token and rotating refresh token (which is probably necessary in this flow (?)) using the code and a code verifier. These tokens can then be saved in Chrome storage. We can potentially also encrypt the tokens but I’m not sure if that offers any additional protection (?) considering that the background script is not the same as a server. 3.) If the Chrome extension wants to receive data from the API server, it sends a message to the background script which will then send the API request using the tokens saved in Chrome storage.