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

Tatsuya Karino <kokuban.kumasan@gmail.com> Fri, 12 March 2021 14:24 UTC

Return-Path: <kokuban.kumasan@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E9D773A0C8A for <oauth@ietfa.amsl.com>; Fri, 12 Mar 2021 06:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.087
X-Spam-Status: No, score=-7.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_HI=-5, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GnMKXtk0Cgvk for <oauth@ietfa.amsl.com>; Fri, 12 Mar 2021 06:24:33 -0800 (PST)
Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2353A0C88 for <oauth@ietf.org>; Fri, 12 Mar 2021 06:24:33 -0800 (PST)
Received: by mail-vk1-xa31.google.com with SMTP id k27so1279483vki.2 for <oauth@ietf.org>; Fri, 12 Mar 2021 06:24:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/yjEF5nlHJcw45EPY/KUPXY2uH0UCvN71tkIJPWsKNQ=; b=kp2gickAhG//yVqMHYfeZNV7H1/9nvDI5qJ7GABfweWGXttSHGYcm0tpYQANGssege yYbQ4B8JtLZGxZ1NH7EOEHegtwEremWKcNQYpcEnx3IYsloub7k6vTXmjgO6VY36vNmx gYvLg1KUA6DbXXpXJDaZGRTShEw1okRf8svzJrW7NOBv1vkGSOA5TOGqLNi6GnJBs/Zp Cp7A0H1ZFDC+AwL2rHO1Ino+gGe9x6KVjqEOBh+ccTS2joJLH8zJt2x6OGI9G4efSmvU VHTCAzwF41EoPu2+3a15rUBAVm3FAtGyv9kUpXZk1xPlfQ/FNCE35Wyx1g64mU4pVQIo bz6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/yjEF5nlHJcw45EPY/KUPXY2uH0UCvN71tkIJPWsKNQ=; b=SQxFIr0OmfWZOqobI2c49fu5crmn+4sMwg7GtN77pptWLE5Y1HDDU6CdaGH1LrB9WC 76QxDf3TbD5ngsmaSMtgIymolK8eeDtzmLmbsQ5ea2JN4dvcUUTigkckp78CMTu4xeeG moFJEitFsPSdRe+bU2dd8nPbIpr9Vd+7AotUXrjnb0ESqiY/iIu4lpqsW1A0tYYQ3i5A PHzModvfXUiFItSdDzeBkoV+DaPPMVWn4p6KJNHityf4zdjd1aJlwt62KCf2e4+aizeN vTuy2QHOVnpqMmc3k4c8xuxd5Vdmqb6tFmXJyjqlyc/aoRl+m2LtlZEjaI7/hhpRG8iG 0kpg==
X-Gm-Message-State: AOAM530pJ6tc7/TfUXJV9Aplm/MRBjWEq17JI6U5kDwh5CrvNb9LscYI KIOQiJPB3WplKgVGjDoA33cBYlYR29HSC0Hw8vR5nIySlQSdAg==
X-Google-Smtp-Source: ABdhPJwmiN6ZXHklaKCYpvGJXrGPVc+huvwb7/FT1XbER4W+MXH7VpPMFyTmEvakgqHiMHUjanpbXalfaSzwNgSCli8=
X-Received: by 2002:a1f:25d4:: with SMTP id l203mr8137620vkl.9.1615559070504; Fri, 12 Mar 2021 06:24:30 -0800 (PST)
MIME-Version: 1.0
From: Tatsuya Karino <kokuban.kumasan@gmail.com>
Date: Fri, 12 Mar 2021 23:24:19 +0900
Message-ID: <CABOQBfuQDC=7e=a2V7HMusdgMeNnaA=sesfgCoPOyrBuWU9c4Q@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000082db0305bd57a8c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8Ghy_eTpD_bJdzfe3aEXVMIJYLk>
Subject: [OAUTH-WG] Re-creation of Access Token on Single Page Application
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 15:44:51 -0000

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

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

  + 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

+ 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

  + 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?


Tatsuya Karino