Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

[Philippe De Ryck <[e-mail]>]

> On 13 Mar 2021, at 07:52, Tatsuya Karino <[e-mail]> wrote:
> 
> By the way, I also wonder what is the better option to use OAuth2.0 on SPA Client (3rd party) with good UIUX.
> In my understanding, there are two options to achieve it.
> 1. Using response_momde=web_message or 2.Using Refresh Token with fixed maximum lifetime.
> 
> But I have a concern on a practical use.
> For 1, Some browser could be restricted to send credential cookie to the authorization server from iframe.
> For 2, The Refresh Token must be saved on the browser, but it could be deleted on 7days in safari.
> 
> Is there any workaround? or Is there any misunderstanding on my concerns?

As you stated, option 1 does not work in cross-site scenarios in Safari & Brave at the moment. Other browsers are likely to follow the same pattern in the future.

Option 2 only works if there are already tokens available, which is typically not the case at first load. Also, keeping long-lived refresh tokens in a browser is not always the best idea.

One workaround goes as follows:
1. When the SPA loads the first time, check if it has token material. If yes, done, if not, go to step 2.
2. Redirect the browser to the authorization server to run a new authorization code flow with PKCE, by setting prompt=none. This will prevent any user interaction and immediately returns either an authz code or an error.
3. The SPA loads again with the autz code/error. If it is a code, it exchanges it for tokens and all is good. If it is an error, the SPA simply shows the unauthenticated state (here, the user can start a new flow with interaction by clicking the login button)

Note that step 2 will include cookies, so it can resume an existing session between the browser and the authorization server. This cookie is always present since a top-level redirect is not a third-party scenario, so third-party cookie blocking does not apply.

Hope this helps

Philippe