Accessing fetch vs tokens, secrets

[josephguillaume]

I'm opening this issue to document/get my head around the current approach to security in resuming a session in solid-oidc.

My understanding of the current situation is:

• it is common practice to have a global authenticated fetch, with some possible attacks on this documented here already
• access tokens should not be stored outside closures
• refresh tokens provide access to new access tokens, but refresh token rotation is considered a sufficient mitigation in some more general oidc settings
• silent authentication without repeated consent is the current standard way of resuming a session, and relies on the client having an authenticated session at the ~authorization server~ OpenID provider

A sharp distinction is therefore made between access to fetch vs tokens and underlying secrets

[josephguillaume]

Existing discussion:

https://github.com/inrupt/solid-client-authn-js/pull/1802 Expose authenticateHeaders method and helpers for Web workers in browsers by rubensworks

• "exposing this method to sign the headers from the function facilitates token extraction and arbitrary usage of the DPoP key"
• "It does not leak any of the internal secrets of the session object, as it just signs the request, within sharing the internal keys"

[josephguillaume]

Existing discussion

https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1058 Solid-client-authn-browser silent authentication is not granted refresh_token (2021)

• "The interpretation I have of the OpenID spec in the matter, which may be a bit far-fetched but sounds technically correct, is that the user must be prompted at least the first time, when no cookie is present. The presence of a cookie indicates that a session is active, and that the user has consented to the scopes requested by the app, therefore prompting the user again is not required."
• "iframe-based silent authentication is prevented by browsers security policies disabling cookies being shared with an iframe"
• "storing the refresh token in the local storage is as bad as storing the access token there"
• "store refresh tokens and use refresh token rotation. Auth0 now recommends this solution. Apparently they recommend tokens being stored in a web worker."

[josephguillaume]

Existing discussion

https://github.com/inrupt/solid-client-authn-js/issues/1682 Prompt=none vs. refresh tokens

• "I didn't mean to imply that refresh tokens aren't insecure by nature, it's just storing them in a shared storage that we want to avoid for security reasons, in order to prevent a third-party script to get access to it and to become able to issue its own access tokens. This is why both access and refresh tokens are only kept in the closure of the fetch function, where they cannot be read after the fetch function has been instantiated."
• "Keeping a reference to the OIDC issuer in localStorage isn't a security vulnerability, and this silent redirect basically re-kickstart a regular authentication process, with an incoming redirect including an authorization code. The client can then exchange this authorization code for access and refresh tokens in the regular fashion."

[josephguillaume]

OAuth 2.0 for Browser-Based Applications https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-19.html