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

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.kumasan@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