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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
