I’ve seen a similar question asked a few times and have a potention solution I’d like to pressure-test with the community.
We have a native app which uses a custom sign-in/sign-up universal login SPA inside a web view to authenticate. It captures the access code and exchanges it for an access token and refresh token. From then on, it uses the refresh token to retrieve new access tokens.
We can’t guarantee that the cookies from the login will be persisted. And even if we could, there’s nothing stopping a user from clearing their cookies independently. In this case, until the refresh token expires, the user will be able to continue using the app in an authenticated manner.
The app also depends on SPAs in webviews for some common functionality. The SPAs are using
@auth0/auth0-react to manage user sessions when running as stand-alone browser apps.
Ideally we don’t want to have to force the user to log in again when they are served one of these SPAs in a webview, and as mentioned earlier, we can’t rely on the session cookies from the original native app login.
@auth0/auth0-react exposes the ability to inject a custom caching implementation, and
getAccessTokenSilently reads from this cache primarily before attempting to get a new access token. So I’m thinking the flow could be:
- App launches the SPA with the access token in the Authorization header. It also injects a
- The SPA injects this token into the cache
- When the token is read from the cache, custom cache logic validates that the token is not expired. If it is expired, it calls the injected
refreshTokentoken function, updates itself, and returns this value.
Effectively the app is enabling the webview to impersonate it. As long as the app is able to maintain an active access_token, it can keep supplying it to the webview, and the webview can operate with this token.
I’m reasonably confident this can work. Just interested in potential security vulnerabilities we’re introducing. The main risk I see is that something other than our SPA manages to get itself loaded into the webview, but I’m not sure how viable such an attack is.