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

Nov Matake <> Sat, 13 March 2021 04:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 015ED3A14B8 for <>; Fri, 12 Mar 2021 20:05:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 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, MIME_QP_LONG_LINE=0.001, 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 UhRFQFGOQULh for <>; Fri, 12 Mar 2021 20:05:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E5973A14B6 for <>; Fri, 12 Mar 2021 20:05:35 -0800 (PST)
Received: by with SMTP id cl21-20020a17090af695b02900c61ac0f0e9so93113pjb.1 for <>; Fri, 12 Mar 2021 20:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Nx7x9MPcUyw0p9FEAVyyyQwk6pWKQR9uAKBTwGOToUY=; b=Kawn0okidxQGLSghuDmP+ySzB2LNjEOsI4DXJ9FkL+na2aPIXz/bsYTjxX59P15oQ0 8Lxos0bJvMm7fvGoWpXnvFwvLuj72agUM/GfnoAXV0vEJ76Qzq1MYXD7yuUwP5B82l0y 3iLqx6PkEQOZjuwtiPY749TNv00KYqkjWiVHNN+XDC0CV4yC8xzzafzwHZ4LyoTAJMBt CnAUz8iB7OXjSIJGpjmNG2S+JCUjkKwhc2t6e8Ub0Vx62tkzk3qx/s6V18LuWYZ+EitW Tx1MH+oBAkmVT/9rs4GRXAyL0SMGkcksjyFEJKj3FHG5wiv0GBQj4vrNJuJo6y3+Z1K+ uAhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Nx7x9MPcUyw0p9FEAVyyyQwk6pWKQR9uAKBTwGOToUY=; b=NICSOsym7hWAaXcCx6omAod9s1Ze8N1sfk3QZE0Bef1FTUrw3gnsFT/JMa/i4CgCZu n1CWjwp698wnFETYtAbhsr9bfPCiaWKOM0Q+oHw81ih9uy7xRU8eBrH9BOCeDkdInkbs pgR6gJr1sxc8l/i0Rbkzb+KZSzgTPBs/a2+hp7paW3UKsBpHH56KgkTdTM5qY1PoUui4 IgiLcKxTnax993x+l2mXDx1v7yM5mKR34TJGY+OaSaZDrNe6x87bmeFWrZqR4X6fPv3A Dr5lpXBcg0w82oqQoVDITjjiUYtcyTTJEUBPkIuC5C1oT3xtQvve08Xx4PejXeV73KFx qF4w==
X-Gm-Message-State: AOAM531+WMOB/Hvh9GRexpIsfjjddgWPPtsaY65PhTQxdbrgi127pzqk FokU3vs6hYJixOaIz9xELbIv3qyXpgE7yg==
X-Google-Smtp-Source: ABdhPJwxf367pBBVUpaa+g7CPujZfHW2LQTkXhQZ6P62u+Lrh1NGWveXOaR7EJsQo+hBvSMDf6J9eA==
X-Received: by 2002:a17:902:7249:b029:e4:358a:1d47 with SMTP id c9-20020a1709027249b02900e4358a1d47mr1768963pll.8.1615608332960; Fri, 12 Mar 2021 20:05:32 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 184sm6478073pgj.93.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Mar 2021 20:05:32 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-C371F736-0350-4F78-8AF3-569A9ED0FD11"
Content-Transfer-Encoding: 7bit
From: Nov Matake <>
Mime-Version: 1.0 (1.0)
Date: Sat, 13 Mar 2021 13:05:29 +0900
Message-Id: <>
References: <>
In-Reply-To: <>
To: Tatsuya Karino <>
X-Mailer: iPad Mail (18D61)
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 04:05:37 -0000

Your mechanism seems work fine.

However, do you need OAuth in such situation?
Same-site cookie seems much simpler there.


> 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