> On Mar 14, 2021, at 8:36 PM, Tatsuya Karino <kokuban.kuma...@gmail.com> wrote: > > 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.
Refresh tokens wind up being a bit more valuable to bridge the state in the two sandboxes and let you get new access tokens. The AS policy can also be adjusted potentially to give longer-lived access tokens when the type of access being granted has less security impact if leaked. > 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... A back-end server only changes access token availability in the case where the AS security policy is that only confidential clients can be issued refresh tokens. If you use a backend to expose/proxy API requests via a set cookie, remember that you need to protect against CSRF attacks. Some sites use the need for a manually-applied OAuth header as CSRF protection. -DW
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
