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

Nov Matake <> Sat, 13 March 2021 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2FDF3A085E for <>; Sat, 13 Mar 2021 00:02:30 -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 uTQduXyFBSbk for <>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D41733A0858 for <>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
Received: by with SMTP id nh23-20020a17090b3657b02900c0d5e235a8so12198077pjb.0 for <>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=PPfYMm0alrnP75NXKvR+apy2e9Ypg4XOca1KtYOyhFc=; b=DCUkMp7HuQHwDQAjO4g70CC60MQhfFkB+2dBjlHBQ4hnKfMRLAl379ScZdHojLyeNj vSYUZUAUJzVAFboyfdyCvlKUH1/LeUhlF/OnjwGIWCPo1p0y0tqgw7pnJRLEFf94cBwg InyvBelUTZ4LlmGGI8A7iN1SrRnMrac4N2YnvjD1ps4+8eh0vfSSRqqbE+D/IRuJc5XS 1/Y9gCu3D/ne6a9EveDODWxCc6GcQsUu6wZQCgRLDGR6Jqviz4JTAIc3Mr936RsZNiY2 6rlHNqfGrAn+rFe2RTnf3Srr2PrSPVymtk8ShT+Vny4ohw5g7nSet1R3SzGHzfu3X0zp 4ZQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=PPfYMm0alrnP75NXKvR+apy2e9Ypg4XOca1KtYOyhFc=; b=tiN1q8P1sMbmO/Megtg3kwy4mbE7OZ4nZJb528ZE1lmR03EfWnjfBncd8RXsQwmMuB gEaf5pTAKJG8mUfFdw5XBNfvTMJIaIRdHIK6JVgJF4YAiMqiIdyCAtDiAWmceuIYPlgh X9N1g9GJ7RiRemAyD3LDSdSQtXMWJL3T8E5pyTnzzJqArLNnbqdq8GPZkOM7StlW02bY GL0iq2qzwMUiDtpLUng5zqPZLPKm79emhjqCFlo4lBbfTkAk4uXhdfiooN9XS7Fvxqje i0VH3bOMs0APOI+a98pbkNteuGgBcNP9X1xFeXa2h/ICjVvissZpCwLMdb97tSQtfMUw kmdQ==
X-Gm-Message-State: AOAM5309lbSClmubjNowq3Y3pWGFKbi3GjyzIgZrm5iVd1wR9Fx/Bn4p pEidkTxFaLxqtRDxOV/J8iP9NbG1EMFW4w==
X-Google-Smtp-Source: ABdhPJwPTv4TyL+7fXA14cwm5vcI5HLTXFmSALEabNan+QSEkBTcq29OShRb+Qi+s4MGzeX2QXFhcA==
X-Received: by 2002:a17:90b:3550:: with SMTP id lt16mr2413924pjb.47.1615622547013; Sat, 13 Mar 2021 00:02:27 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id o9sm8061804pfh.47.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Mar 2021 00:02:26 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-3DDFB2D9-6CE7-46D8-AB8B-07F36F813A30"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Nov Matake <>
In-Reply-To: <>
Date: Sat, 13 Mar 2021 17:02:25 +0900
Message-Id: <>
References: <>
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 08:02:31 -0000

On Safari, you have no workaround.
3rd-party cookie is dead, and all JS-writable data is removed in 7 days there.

What you can do is open popup or call storage access api each time you need new token.


> 2021/03/13 15:51、Tatsuya Karino <>のメール:
> > 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 <>:
>> 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