Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application
Nov Matake <matake@gmail.com> Sat, 13 March 2021 08:02 UTC
Return-Path: <matake@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FDF3A085E for <oauth@ietfa.amsl.com>; Sat, 13 Mar 2021 00:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTQduXyFBSbk for <oauth@ietfa.amsl.com>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 D41733A0858 for <oauth@ietf.org>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id nh23-20020a17090b3657b02900c0d5e235a8so12198077pjb.0 for <oauth@ietf.org>; Sat, 13 Mar 2021 00:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 [172.16.80.55] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id o9sm8061804pfh.47.2021.03.13.00.02.26 (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 <matake@gmail.com>
In-Reply-To: <CABOQBfsDpwFHbd5U+1YHDnRQUNZ7Mqqk6w+BA0cLrW7OqkuPvg@mail.gmail.com>
Cc: oauth@ietf.org
Date: Sat, 13 Mar 2021 17:02:25 +0900
Message-Id: <4D1CB4B4-03D9-40B5-8472-9B63661F9518@gmail.com>
References: <CABOQBfsDpwFHbd5U+1YHDnRQUNZ7Mqqk6w+BA0cLrW7OqkuPvg@mail.gmail.com>
To: Tatsuya Karino <kokuban.kumasan@gmail.com>
X-Mailer: iPad Mail (18D61)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/v92MOJen4L-C7tLwxtVcOf5q3Xg>
Subject: Re: [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: 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. iPadから送信 > 2021/03/13 15:51、Tatsuya Karino <kokuban.kumasan@gmail.com>のメール: > > > 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 <matake@gmail.com>: >> 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 <kokuban.kumasan@gmail.com>のメール: >>> >>> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > > > -- > Tatsuya Karino
- [OAUTH-WG] Re-creation of Access Token on Single … Tatsuya Karino
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… Nov Matake
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… Tatsuya Karino
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… Nov Matake
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… Philippe De Ryck
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… Tatsuya Karino
- Re: [OAUTH-WG] Re-creation of Access Token on Sin… David Waite