Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

"Brock Allen" <brockallen@gmail.com> Fri, 18 May 2018 12:46 UTC

Return-Path: <brockallen@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 81C4412D887 for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 05:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 C9ukVJ-h3NNZ for <oauth@ietfa.amsl.com>; Fri, 18 May 2018 05:46:25 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 55F3A12D88B for <oauth@ietf.org>; Fri, 18 May 2018 05:46:24 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id v132-v6so2354004ywc.6 for <oauth@ietf.org>; Fri, 18 May 2018 05:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=y5noYjXnaXJqUdiK2/xhULkq7W3BRDCIH2YIVDMRFao=; b=NJAxwIIuJuMqTfTxEKP27faRhn7fxP4YCDIxcKd1IDrpybxkQxgu7iXT0INhU9fCs7 PhMGbQTaheqenGzcGjzdanoKEd6hrp7m4xwd5aptNC3IfCL0CDYYCPIoQsybR4noDIPW y1DEN6ddhUfiCFBDWg1v1u1toTy9Rc8AFfn1YGiNJcI3w8yWBrotKbK2MQtTMeodPuwT TbHgKRnUpY2M3UtF1i/NVaXa2JlqL9tUMG5/29W3upsVLgJOFuXDzDAe9eI0+zIuqL/Q Ovr+xBefiPeGa/adWgWO8DIYTu3NVSfaP86Ugh3OFQguim5QxHjWgnwXhSTRHYJrx8xh 6r4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=y5noYjXnaXJqUdiK2/xhULkq7W3BRDCIH2YIVDMRFao=; b=iWd5ZFEVnsRMHhkRy1jAFhCnR+0NinFAZrjyNIx6aDgvZ9FZ/KxS0Rwfegqq5+wJBF hteXbAIQp7peuJeM/UVo970JtAOCTZNI6V7dvdo3FCp9IeB+nUVU4fYDWInpEwbM3zKF 0TM39OaJA+GMEymU5WKcCzcfMhZw9OJiHd6/Qga6tRt8UEV5GmkMW/fMulNihSphXTyT laL4BWVIhDSFePBagr7JHwZOFrKq5Xr8q66kgt1ZnxBmB8L/T7qxcpezD4yXYi4IDG3x CkVb5VqvQfH09KrMzJHShspdnuJYU4qyvKcvospE7ThppgJhpdysPcvJ/Vf8vB2I8jTh whuQ==
X-Gm-Message-State: ALKqPwdfrdnnkVHXvcI3IyPhxkglayNKIr2JXwFZnZ5gDlKI6mI3CGBA tJsKKS+/eZsyIPzzdaM35zM=
X-Google-Smtp-Source: AB8JxZq/E96cPprFFbUuzEtFyy81ABPrKHgw9RBoW69WNVIRmeBQivhIQnfC1RR/EyoVJXQ3LArEdg==
X-Received: by 2002:a0d:f3c7:: with SMTP id c190-v6mr4480473ywf.353.1526647583279; Fri, 18 May 2018 05:46:23 -0700 (PDT)
Received: from [172.20.10.3] ([172.58.153.135]) by smtp.gmail.com with ESMTPSA id 205-v6sm2950527ywv.79.2018.05.18.05.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 May 2018 05:46:22 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_16116096.568679140624"
MIME-Version: 1.0
Date: Fri, 18 May 2018 08:46:14 -0400
Message-ID: <895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com>
From: "Brock Allen" <brockallen@gmail.com>
To: "David Waite" <david@alkaline-solutions.com>, "Hannes Tschofenig" <hannes.tschofenig@arm.com>
Cc: "" <oauth@ietf.org>
In-Reply-To: <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com>
References: <ab42d84a-5f08-4600-aa36-92e73944cf6c@getmailbird.com> <VI1PR0801MB2112A6F8B47939F8748DEA43FA910@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4B744041-8E6D-489C-8162-CE690C42543B@alkaline-solutions.com>
User-Agent: Mailbird/2.5.8.0
X-Mailbird-ID: 895b7769-e2e9-4ce2-bc29-6abb6ba44732@getmailbird.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/MlSpcD7LkL3-kCWC7XJs6fF2wcg>
Subject: Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 18 May 2018 12:46:28 -0000

One thing I maybe should have listed in the pros/cons in my original email is session management and token lifetime considerations, keeping in mind the original intent of the implicit flow.

What I mean is that with implicit grant type, the client's ability to get new access tokens is limited to the user's session at the AS/OP. Obviously other flows make more sense to obtain longer lived access (via refresh tokens), but I don't know about a browser-based JS app. In a sense there's a bit of protection for the end user built into that design by virtue of being tied to the user's cookie at the AS/OP.

Just throwing that out as an additional discussion point.


-Brock

On 5/18/2018 6:04:47 AM, David Waite <david@alkaline-solutions.com> wrote:
I have written some guidance already (in non-RFC format) on preferring code for single page apps, and other security practices (CORS, CSP). From the AS point of view, it aligns well with the native apps BCP. There are benefits of thinking about native and SPA apps just as ‘public clients’ from a policy/properties point of view. It also greatly simplifies OAuth/OIDC support on both the AS administrator and client developer side when converting web properties into native apps using technologies like Electron or Cordova.

For the later requirements in the list around token policy, I am not sure these are requirements for single page apps per se. I don’t believe the need for a policy using short-lived refresh tokens, revoking at signout, or use of the revocation endpoint are different from browser and native applications. Rather they seem to be a function of usage patterns that an AS may need to support, and we happen to sometimes associate those usage patterns with typical usage of native apps vs of browser apps. For example, browser login on a borrowed device can easily leak over to being app authorization - the authentication/authorization are web-based processes to achieve SSO.

I have been working on some guidance here around token lifetimes and policies, but I don’t know whether that brings in too much AS/OP business logic (and, likely implied product/deployment features) to be industry practices.

-DW

On May 17, 2018, at 10:23 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com [mailto:Hannes.Tschofenig@arm.com]> wrote:

Hi Brock,
 
there have been several attempts to start writing some guidance but so far we haven’t gotten too far.
IMHO it would be great to have a document.
 
Ciao
Hannes
 
From: OAuth [mailto:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]] On Behalf Of Brock Allen
Sent: 17 May 2018 14:57
To: oauth@ietf.org [mailto:oauth@ietf.org]
Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps?
 
Much like updated guidance was provided with the "OAuth2 for native apps" RFC, should there be one for "browser-based client-side JS apps"? I ask because google is actively discouraging the use of implicit flow:
 
https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 [https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290]
 
>From what I can tell, the complaints with implicit are:
* access token in URL
* access token in browser history
* iframe complexity when using prompt=none to "refresh" access tokens
 
But this requires:
* AS/OP to support PKCE
* AS/OP to support CORS 
* user-agent must support CORS
* AS/OP to maintain short-lived refresh tokens 
* AS/OP must aggressively revoke refresh tokens at user signout (which is not something OAuth2 "knows" about)
* if the above point can't work, then client must proactively use revocation endpoint if/when user triggers logout
 
Any use in discussing this?
 
-Brock
 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth mailing list
OAuth@ietf.org [mailto:OAuth@ietf.org]
https://www.ietf.org/mailman/listinfo/oauth [https://www.ietf.org/mailman/listinfo/oauth]