Which UI do you use?

Custom UI

Pre built UI

Active session can't change auth-modes

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-10-25

Last updated:

2022-11-24

Context and Problem Statement

We need to decide if we can upgrade in get/verifySession on refresh calls

Considered Options

• All
• Refresh only
• None (change in settings only take effect when creating new session)

Decision Outcome

Active session can't change auth-modes. Reasons:

• Allowing it in all request would increase implementation complexity for not much gain and it'd make our vulnerability of XSS attacks worse.
• If we allow changing the auth-mode during session refresh we increase the attack surface of XSS.
• An XSS attack could still steal tokens by changing the auth-method during sign-in, but in this case they could also capture the user credentials.
• This means that changing the default auth-mode in the frontend SDK will only have effect after the user logs in again.

As a consequence:

• Refresh session will not change the auth-mode of incoming requests.
• In case both cookies and headers are there, we default to headers (see here)
• Respecting the auth-mode header in case both exist during a refresh call would provide no real advantage:
  • this should not happen while using a FE SDK:
    • when refreshing or creating sessions we clear the token transfer methods we are not using (e.g.: we clear cookies when creating a session using headers).
    • there can be some edge cases (changing versions back-and-forth during development): we are not optimising for this
  • the most likely case is someone sending manual requests:
    • Headers should take priority as that's more likely to be intentional.
  • it could be an attacker through XSS:
    • even if we reject this/use cookies, they could call logout to clear old cookies before adding their own tokens, completely replacing the session
• In case both cookies and headers are there, refresh will clear the one we are not using.

Expected behaviour of refreshSession as a table

getTokenTransferMethod	Authorization header	Refresh token cookie	Output	Set tokens in	Cleared tokens
*	none	none	UNAUTHORISED	-	none
any	none	exists	Validate refresh token from cookie	cookies	none
header	none	exists	UNAUTHORISED	-	none
cookie	none	exists	Validate refresh token from cookie	cookies	none
any	exists	none	Validate refresh token from header	headers	none
header	exists	none	Validate refresh token from header	headers	none
cookie	exists	none	UNAUTHORISED	-	none
any	exists	exists	Validate refresh token from header	headers	cookies
header	exists	exists	Validate refresh token from header	headers	cookies
cookie	exists	exists	Validate refresh token from cookie	cookies	headers