> On 13 Mar 2021, at 07:52, Tatsuya Karino <kokuban.kuma...@gmail.com> 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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to