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 <kokuban.kuma...@gmail.com>のメール: > > > 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 <mat...@gmail.com>: >> 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 <kokuban.kuma...@gmail.com>のメール: >>> >>> 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
