Re: [OAUTH-WG] best practices for implicit grant / token storage

Jim Manico <jim@manicode.com> Thu, 08 September 2016 19:51 UTC

Return-Path: <jim@manicode.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 3119112B047 for <oauth@ietfa.amsl.com>; Thu, 8 Sep 2016 12:51:55 -0700 (PDT)
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=manicode-com.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 XKaG4RjZZ-6p for <oauth@ietfa.amsl.com>; Thu, 8 Sep 2016 12:51:53 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 12FE712B02F for <oauth@ietf.org>; Thu, 8 Sep 2016 12:51:53 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id w87so21254506pfk.2 for <oauth@ietf.org>; Thu, 08 Sep 2016 12:51:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xj09Majj4sDgfoiZ97kpJOfgDhtt1VXK4ONju/+v6p8=; b=IEyVcqvTUPoLD+Tex21S1roIsV3vjZEOKgL/Fg0gP4aCG/ZAhGIDYX3I8oq1cTknn+ z/3O+CHTprKUwyV1EjJFLfcmqtLOuh1WlW9+QbYoOYRxK+1AgoEvT0Z2TiUTumBp1jyB WTt3yGpZjnlZnXqhAldw+FodAdpObrQ9Am9W1KQ+Tbxy4oDxagQG9mFk9C4y4cV/Ac+1 Ww9Q2VlIIOEiuvuXUWvZjbpYp/qWqWZwObaZcdl2KhGur9kE2B8fzFNix5mcfEU8q6K7 CSEhpi/i20QgA4U8286jdB0NIRZhtfU+q5zLDsKm4HT6vOZLr2N64mgw6G2F6/TfZmE9 cBvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xj09Majj4sDgfoiZ97kpJOfgDhtt1VXK4ONju/+v6p8=; b=AepCaD4saMDvsUSPucFellFbKuzQ6C4MEqxze7zfZRLAvdvOWoYRDrpSL1nBcjRohw joOI/7BKfDrIXCY/3fa2WhFwdKNJSq4fwO7pjq4LcmjswZroxbeg/jcAME2Pz4rXsf3m AQLXf4SKXCQ9fcWu65SkTBOqmSlWMoFrGQGltdXwEF4GZKbryPvo4vTIzxKzVnkWs9nQ ls6phQhVcOYPwT9qXYK8rlb0Q8/080ajwEluFfHyICneBnA5qZgMjffMZUEdZF4yRP5m b6BmlI6kvYmceyWzWmtMqbcIJilmsp+e8KWW1Hkti5TKnYo+N/un3U3uS8Rje542Xrv1 D3AA==
X-Gm-Message-State: AE9vXwP2ABdOFfwymRhaBgrxvtTXB4PvJPpnibONusM1CzCYbIbSNHjLK35japCBICyxEW+J
X-Received: by 10.98.106.65 with SMTP id f62mr2423231pfc.107.1473364312518; Thu, 08 Sep 2016 12:51:52 -0700 (PDT)
Received: from heembo.local ([2605:e000:112b:c167:3ccb:e369:74b0:50fc]) by smtp.googlemail.com with ESMTPSA id px7sm6490310pac.41.2016.09.08.12.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 12:51:51 -0700 (PDT)
To: Oleg Gryb <oleg@gryb.info>, Adam Lewis <adam.lewis@motorolasolutions.com>
References: <CAOahYUzu3zH3ZR2HTUmN6Jp6W5Oo1XvR7G=k=FRN7RAHda8m-g@mail.gmail.com> <FB0A62F2-AD7E-4257-B993-C9E8D3BD989D@manicode.com> <632483756.1929562.1473358500330@mail.yahoo.com>
From: Jim Manico <jim@manicode.com>
Message-ID: <49c750b1-83e4-cdd3-1bab-3ae005810e66@manicode.com>
Date: Thu, 08 Sep 2016 09:51:48 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <632483756.1929562.1473358500330@mail.yahoo.com>
Content-Type: multipart/alternative; boundary="------------465714FFA2F34DCCEA9FC0DF"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VEEwxOb9iWuuHvdxE_kqDOZDs0A>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] best practices for implicit grant / token storage
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: Thu, 08 Sep 2016 19:51:55 -0000

> Since SPA is a new normal now, it becomes extremely difficult to
enforce HTTPOnly flag, because JS needs access to secrets including
those stored in cookies.

In a browser environment, this is only true when you need to make cross
domain requests or are using cookie data for something other than
session state.

If your current page origin and the page you are requesting are the
same, then your cookies can be HTTPOnly without impacting functionality.
If you need additional cookies for other things that need to be accessed
via JS, use a separate cookie.

So sure, there are a few workflows in OAuth where you need to access
"cookie data" from JS and HTTPOnly is not viable. But there are a few
where it is viable. I don't think it's as simple as "we need to talk to
cookie data via JS all the time.".

Aloha, Jim

On 9/8/16 8:15 AM, Oleg Gryb wrote:
> Jim,
>
> It's outdated a bit. Since SPA is a new normal now, it becomes
> extremely difficult to enforce HTTPOnly flag, because JS needs access
> to secrets including those stored in cookies. 5-10 years ago I would
> always enforce HTTPOnly and now - I can't.
>
> Thanks,
> Oleg.
>
>     ------------------------------------------------------------------------
>     *From:* Jim Manico <jim@manicode.com>
>     *To:* Adam Lewis <adam.lewis@motorolasolutions.com>
>     *Cc:* OAuth WG <oauth@ietf.org>
>     *Sent:* Thursday, September 8, 2016 10:45 AM
>     *Subject:* Re: [OAUTH-WG] best practices for implicit grant /
>     token storage
>
>     In the web world, cookies for session identifiers are much safer -
>     since we can use HTTPOnly cookies to protect them from theft via
>     XSS. The same mechanism is not possible for localStorage. Overall,
>     security folk say •keep sensitive data out of localStorage• since
>     one XSS and it's stolen. There is also a huge body of work
>     underway to make secure cookies even more so.
>
>     I'm not sure how this translates to native apps.
>
>     --
>     Jim Manico
>     @Manicode
>
>     On Sep 8, 2016, at 3:02 AM, Adam Lewis
>     <adam.lewis@motorolasolutions.com
>     <mailto:adam.lewis@motorolasolutions.com>> wrote:
>
>>     Hi,
>>
>>     The WG is currently putting together best practices for native
>>     apps.  I would like to better understand the best practices
>>     around ua-based-apps, especially as it relates to token storage. 
>>     I've read various blog posts about the preference between storing
>>     tokens in cookies vs.  Web Storage
>>     (localStorage/sessionStorage).  The current set of specs are
>>     rather silent on the matter, as it is more of an implementation
>>     issue (but that is where most mistakes are made).
>>
>>     What is the WG's guidance on this?
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com