important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Ignore Authorization header set by the user if it matches the access token

Status

This is just a proposal so far, it hasn't been accepted and needs further discussion.

Status:: proposed
Deciders:: rishabhpoddar, porcellus
Proposed by:: porcellus
Created:: 2022-12-06

Context and Problem Statement#

If the user sets the access token (that's the same as our access token) as the authorization header (like what you have to do for some other SDKs), it can cause issues with automatic refreshing. The issue happens when after a refresh, we retry the request with the same headers provided by the user. Therefore, we will use the same expired access token instead of the new access token causing an infinite refresh loop

Considered Options#

Disable automatic refresh/retry if authorization header is set
Ignore authorization header if it matches the access token
Throw error if the authorization header matches the access token

Decision Outcome#

We will ignore the authorization set by the user if it matches the access token, because:

People expect the need to set the authorization header, so they might do so even if they shouldn't
If they do this with something else in the authorization header, a 401 will still cause an infinite refresh loop. People can work around this by changing the status code via the sessionExpiredStatusCode config
While the infinite refresh loop is a problem, it's very noticable and causes early (and easy to fix) failure.
If we disable the automatic refresh feature, people may miss the reasoning for this and think that the feature is not working (even if we log a warning).
We prefer silently making this work instead of throwing an error, because that would create friction during implementation.