On Safari, you have no workaround.
3rd-party cookie is dead, and all JS-writable data is removed in 7 days there.
What you can do is open popup or call storage access api each time you need new
token.
iPadから送信
> 2021/03/13 15:51、Tatsuya Karino のメール:
>
> > However, do you need OAuth in such situation?
> > Same-site cookie seems much simpler there.
>
> yeah, right. For a 1st party application, we don't need to use the delegation
> of privilege.
> Using Same-site cookies is simple.
>
> But I also think if the company provide their APIs to 3rd party applications,
> it is a little heavy to provide two types of AuthN/AuthZ system (for 1st
> party and for 3rd party).
> Providing same AuthN/AuthZ system to 1st and 3rd party is more sophisticated,
> I think.
>
> But in this case, the feature that can be used only for 1st party (my first
> mail example) is not acceptable lol.
>
>
> 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?
>
>
> 2021年3月13日(土) 13:05 Nov Matake :
>> Your mechanism seems work fine.
>>
>> However, do you need OAuth in such situation?
>> Same-site cookie seems much simpler there.
>>
>> iPadから送信
>>
>>> 2021/03/13 0:45、Tatsuya Karino のメール:
>>>
>>> Hi all,
>>>
>>> I'm looking for the specification to generate a new Access Token with
>>> authentication session in a Single Page Application with good User
>>> Experience. There is a draft, OAuth 2.0 Web Message Response Mode. And it's
>>> called silent authentication on Auth0. When I read the draft, I got a
>>> question about verifying the receiver of an auth code.
>>>
>>> The summary of the flow with response_mode=web_message is like this,
>>> + The client (main window) creates an invisible iframe.
>>> + An authorize request is sent to authorization server with authentication
>>> session on the cookie.
>>> + The authorization server checks the authentication session and user
>>> consent .
>>> + If it is ok, the authorization server returns an auth code with
>>> Javascript code.
>>> + The auth code is delivered to the client (main window) by Web Message on
>>> the Javascript code.
>>>
>>> I understood this specification like that,
>>> Returning auth code to the browser itself is acceptable.
>>> What we want to prevent is sending the auth code to a malicious client.
>>> It is prevented by restricting receiver of auth code by Web Message in this
>>> spec.
>>> It is same for other response_mode.
>>>
>>> Then I wonder if it is possible to achieve the situation by CORS settings.
>>>
>>> For example like this,
>>> + The client (SPA) send an authorize request from Javascript with the CORS
>>> settings.
>>> + Access-Control-Allow-Credentials: true
>>> + The authorize request is sent with authentication session on the cookie.
>>> + The authorization server checks the authentication session and user
>>> consent.
>>> + If it is ok, the authorization server returns a response that includes
>>> auth code with CORS Headers.
>>> + Access-Control-Allow-Origin: domain specified for each client like
>>> redirect_uri.
>>> + Access-Control-Allow-Credentials: true
>>> + The browser checks the origin if the domain is same with that one used
>>> for client application.
>>> + If the preflight request is happened, this check will be done before
>>> generating auth code.
>>> + If it is ok, the client receives the auth code.
>>>
>>>
>>> I feel that the use case is quite small because authorization server and
>>> client have to be provided on the same eTLD+1 at least for the safari. But
>>> the implementation would be very simple, so it could be used if the company
>>> has 1 authorization server and multi clients.
>>>
>>> Is there any specification like that? or What kind of security issues are
>>> there in the flow?
>>>
>>> Thanks!
>>>
>>> --
>>> Tatsuya Karino
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Tatsuya Karino
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
