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

[Tatsuya Karino <[e-mail]>]

> 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 <[e-mail]>:

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

-- 
Tatsuya Karino