IETF Logo Mail Archive

Re: [OAUTH-WG] SPA applications best practice

Samuel Erdtman <samuel@erdtman.se> Tue, 28 February 2017 05:56 UTC

Return-Path: <samuel@erdtman.se>
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 DA96312941E for <oauth@ietfa.amsl.com>; Mon, 27 Feb 2017 21:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.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 ehrY59QkrwKE for <oauth@ietfa.amsl.com>; Mon, 27 Feb 2017 21:56:26 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 22D831294CD for <oauth@ietf.org>; Mon, 27 Feb 2017 21:56:25 -0800 (PST)
Received: by mail-oi0-x22a.google.com with SMTP id 2so1126614oif.0 for <oauth@ietf.org>; Mon, 27 Feb 2017 21:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eX91t2wMOkxlLIkQhDp2n5y4lVHGn2A6KW9mN3g6AMM=; b=kVpVyc+q0lHg76svVpZziC7K2Ly/CzWK40s9NBIr45P8cZRL3SCfmWB+HswqpP3ZNB OJ8Tbd1kruuUeA1J4j836LyaWb50v0wHzXuXNgioTx202H0ewqP7ZHxAPijciVJ5Hw6K IVJGsXkJfg7pLJUKFUezKEnDMc3rbvUF1Wnq4VGxiibRc8IfoYPag0peqHYpqe3FVgkT 6JImAYYEWLHpT2h4/JFDQQFftBIEIl616r2dGzW0PBi6TBgjrT5HNzuHnhCdguF/OMTA 5uRdOh13G/xHrvrKJWnTaydyyDIvOzmdQvwURKhBRBcQ8Os1VHR5WlHZ+lUt+KgoL4tX lEGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eX91t2wMOkxlLIkQhDp2n5y4lVHGn2A6KW9mN3g6AMM=; b=gHAX+9zMy5sVWsf/l2DbsRLJ9ugdH+ydHb+D42O7xx5aPsdz3JN1itMj5PTDtMvzdj 3D+MJhri6+4EsX/bFIpmEp+dUBGVvaPzd8IghF+KsRJdBSqMsVgymGlSAP03Y5/8t39Q 3uU/Eg3hk3l/qwT+o9sWdxJhwnR+gZB8fP+iWcgRoJvkfrad+PVJY4cQvhKkoQHUebxr qQZH7EIlOre3jhbvN32VxS9POIo03XqEeUPp0sbNPytapebdFdDXU0pFrncMJjLyW0hP GyBveqDhiXUWHS+ECfkZeC1/Zg96Gm/6KGOQToGfZ9zdHkLbyGpFpLaE8ZqrOdben5+B Rp+A==
X-Gm-Message-State: AMke39nc10pP7t6ZXRpJZpMZBIjrrT5KrjB8QHXT01JfTp0hHFLOO5imyyDUjKWGnKG4ATp+TaUZPRyCMkPhgA==
X-Received: by 10.202.7.68 with SMTP id 65mr313939oih.34.1488261384949; Mon, 27 Feb 2017 21:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.125.40 with HTTP; Mon, 27 Feb 2017 21:56:24 -0800 (PST)
In-Reply-To: <3E02AA83-983E-4529-ABE0-6017829AD28E@manicode.com>
References: <3E02AA83-983E-4529-ABE0-6017829AD28E@manicode.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Tue, 28 Feb 2017 06:56:24 +0100
Message-ID: <CAF2hCbYbb=89x0BNiB_n+F3YqQ9CwWR6cx35Bfy6XhQ8zK_WAw@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Content-Type: multipart/alternative; boundary="94eb2c13f2482ee5ad054990db3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/b2pgh3hIcM9w7zbzvhvZLSDUYak>
Cc: IETF OAUTH <oauth@ietf.org>
Subject: Re: [OAUTH-WG] SPA applications best practice
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 28 Feb 2017 05:56:28 -0000

Hi Jim,

If there is enough information I think such RFC could be interesting in the
same way as  "OAuth 2.0 for Native Apps" (
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07) is for native
app.

To see if the group also thinks so I would suggest to create a personal
draft and ask it to be adopted as a working group item. (I´ll send you a
direct message with some details on how to do that)

Best Regards
Samuel Erdtman


On Mon, Feb 27, 2017 at 3:17 PM, Jim Manico <jim@manicode.com> wrote:

> I've been collecting opinions about the best OAuth2 workflows for SPA
> applications and have come up with the following basic recommendations.
>
> 1) The more secure flow is going to be authorization code. Keep access
> tokens out of the DOM/Browser history.
>
> 2) Implicit flows are your only choice if you allow serverless JS clients
> to access your OAuth endpoints. This is much easier to implement but
> carries a great deal more risk. Wether or not this is good for you depends
> on your threat model and risk tolerance.
>
> I'd love to keep going and turn this into a RFC but this is over my head.
> Does anyone here with more experience care to assist in proposing a
> SPA-OAuth RFC? I'd be happy to help with the grunt work. This is one of the
> main areas of OAuth where answers are fractured and I'd love to help push
> more clarity here.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email