Is storing the access token in the user's session secure?

[brechtm]

The Web App Example of OAuth 2 web application flow included in the documentation uses a Flask session to store the OAuth2Session state and access token. Since the Flask sessions are stored unencrypted client-side in a cookie, I'm worried about the security of such a set up.

Should we avoid storing this data in the session cookie? If so, the documentation should warn the user about this, and provide a better alternative (server-side sessions).

[JonathanHuot]

Waouw, I'm not a flask user but it looks very serious.

[OrangeDog]

The only person who can see the session data is the user whose session it is (cookie is secure, httponly).
There is no reason that the access token should be a secret from them.

[snydergd]

During a user's interaction, an app may access/hold credentials or data that the user is not authorized to have.

If the app were to put either of these into the user's session expecting it to be a secure place to hold it (for example, as part of a wizard interface that goes through multiple pages), this could be a problem, especially for J2EE developers who are used to storing all sorts of internal objects/details in the session. However, in general sessions are meant for user-specific data and people don't generally store application secrets/data there.

Encrypting the session instead of simply signing it would help prevent this mistake from being made even in those cases.

OrangeDog is right that having the token unencrypted in an HttpOnly cookie is no less secure than having it in local storage and Authorization headers. The only code the browser exposes it to is the server code (via header) that the cookie was created for. It's arguably more secure than local storage (used by MSAL in some cases, as an example), where XSS code could get it. If this cookie provides no access that the user doesn't have anyway, then there is no weakness.

Summary: User secrets/data are OK to store in the session. Broad app secrets/data are not, unless the session cookie were to be encrypted instead of simply signed, or stored on the server instead of a cookie.