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

Tatsuya Karino <> Sat, 13 March 2021 06:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BA5D3A0E8D for <>; Fri, 12 Mar 2021 22:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BKBGW8S19X0u for <>; Fri, 12 Mar 2021 22:51:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25D8A3A0E88 for <>; Fri, 12 Mar 2021 22:51:50 -0800 (PST)
Received: by with SMTP id 11so1744932vkx.6 for <>; Fri, 12 Mar 2021 22:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f9kdXArTxDf/SOZIM3I+xzkSGXf8RhdA9K3lE8Q2JNM=; b=dzLfzt5A2HD+uE2bJeeKUmo+18B/WnZ3m5nFr2dtqrQNBkULUbZfHoGYSWqFN5khk2 mIwHOIfrzGUsefQkZWQ56y3jnN+mWbe8H+J7OL5bF/5rlqXH9SHaE+wYJjk8X/5BueZ3 9RveVEKkZaNESLBEW0EpP6PMBNP8AYAsGsE9pA4uW/J6nKSjLSGLwfX20PiBqrqL7RUw zklhYAyM2IvDg75BY2QBM4zPb6MYG4SFS2E6HlpbVVXeCZCNhU9e4fkl/pMw4yQiPUZY cUCrAXfpQx6xYUbhPPjr6V6tqqTEReQ+fD9D0lUVuq9V7zhb4xhHUC+8lzwdzOqHdgkw WeZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f9kdXArTxDf/SOZIM3I+xzkSGXf8RhdA9K3lE8Q2JNM=; b=FTUNjP/xqisUawpVVQa88ADL1sQrVtVdN63JVYNxgVMkZ2HQ/N0jfelU2UY6XMlyyJ YPZ1VZaLrB+OGuYb7jZhVroOwVZbD2cjytvefnFiQzamnEaJKjvKEZ0xCJeheDcN0Dm6 F0O44z6/eL8g+X1glJrjnqlAigz+AfSzbM7weIigdRiluF9utHfhUP6t4mrAPLKja+Zh ndBxcxitSvWpLPuFPHWIN4Jk0U66iJgr/4MXRgHAoebezLAGkElMyzejiATQFYWyHleW kQVY0hnYMNqY4/7+kcWsv82X3ksegeFC53Ypyc2+4/ZLLSyxnx5T97QUzSLRazmuRy21 KexA==
X-Gm-Message-State: AOAM531IcRKdXVb7FYXUXb1RU87uO9/L3sXZEHm466AXVhq2ifMLtEcV Aty2PzaderYLvzfJ7lYNlQ3tzp1+fFQt76f9JX4=
X-Google-Smtp-Source: ABdhPJxLFXU66LSxR3yFxAqODVI5Cx8BwmOnz+afiusj2QiReGNTRgIIqsF/g8l3tZ8/l8R3ubaN1cLUVV+jr8vhDBw=
X-Received: by 2002:ac5:c7b9:: with SMTP id d25mr10432726vkn.24.1615618308193; Fri, 12 Mar 2021 22:51:48 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tatsuya Karino <>
Date: Sat, 13 Mar 2021 15:51:36 +0900
Message-ID: <>
To: Nov Matake <>
Content-Type: multipart/alternative; boundary="0000000000005a3f8005bd6573d3"
Archived-At: <>
Subject: Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Mar 2021 06:51:54 -0000

> 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

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 <>:

> 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 <>のメール:
> 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

Tatsuya Karino