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

[David Waite <[e-mail]>]

> On Mar 14, 2021, at 8:36 PM, Tatsuya Karino <[e-mail]> 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