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

[Tatsuya Karino <[e-mail]>]

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
<https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00>. 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