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

[Tatsuya Karino <[e-mail]>]

>
> On Safari, you have no workaround.
> 3rd-party cookie is dead, and all JS-writable data is removed in 7 days
> there.


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.


I see... Thank you. I understood that it is difficult to re-creation Access
Token silently. As reading your workarounds, I felt handling AccessToken
inside SPA is a little difficult.

Generally speaking, preparing Backend Server looks better from a security
and UIUX point of view. If there is a Backend Server for the SPA, we can
use the Backend as a Confidential Client, and create a session and save it
on http only cookie for the SPA. If we have a human resource to do so...

Thank you for your help!

2021年3月13日(土) 17:21 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
>
>
>

-- 
Tatsuya Karino