> > 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 <phili...@pragmaticwebsecurity.com>: > 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 > > > -- Tatsuya Karino
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
