IETF Logo Mail Archive

Re: [OAUTH-WG] best practices for storing access token for implicit clients

Doug Tangren <d.tangren@gmail.com> Tue, 12 July 2011 00:31 UTC

Return-Path: <d.tangren@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 9BD7511E8158 for <oauth@ietfa.amsl.com>; Mon, 11 Jul 2011 17:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCB5FXDC25sA for <oauth@ietfa.amsl.com>; Mon, 11 Jul 2011 17:31:07 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 879B611E80BA for <oauth@ietf.org>; Mon, 11 Jul 2011 17:31:07 -0700 (PDT)
Received: by gyd5 with SMTP id 5so2088378gyd.31 for <oauth@ietf.org>; Mon, 11 Jul 2011 17:31:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9azX3boH218TRrJ9e/hnhG77UuISOkUDHOxQ4AXMk/I=; b=b24LhAUk29x29nasNifW7QXiLrWbx8jsfpvugyIAFQMF7RWCls/CG0GP7vUhJYuW+g tEKRTBhHejdj+v03MyGikNZ8GaAxfvqf+9WYS7H691DyFKyq+cdHFYHvhs4c9YwONBRr StjvS28j8H2aa4MUrZp2PEE8yjs141yePc5Ro=
Received: by 10.90.2.6 with SMTP id 6mr4829123agb.7.1310430666261; Mon, 11 Jul 2011 17:31:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.113.14 with HTTP; Mon, 11 Jul 2011 17:30:46 -0700 (PDT)
In-Reply-To: <CAKMDUCaHUZjeGxBqwSht8wLAtuZAC-P+3LogyGAbYLhV9qUPZw@mail.gmail.com>
References: <BANLkTimU=RGHpHJTb97xvnpaqxqbc_qLhw@mail.gmail.com> <CAGdjJpLBg7-998tZm1uYQ2brsgfc7kyEr7VdF4Rd6ns+CAQGmA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234501D4A042D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAKJ-YRbXQrTDRRsPbo+O3EVJH8CJAj1Cfn8ArT+qboEHC_GuFw@mail.gmail.com> <CAKMDUCaHUZjeGxBqwSht8wLAtuZAC-P+3LogyGAbYLhV9qUPZw@mail.gmail.com>
From: Doug Tangren <d.tangren@gmail.com>
Date: Mon, 11 Jul 2011 20:30:46 -0400
Message-ID: <CAJ2WPXgzacs3YQ4kK43z6Yvg9=HriAe1qTk6Gu2hHaBOAnzv5w@mail.gmail.com>
To: Ian McKellar <ian@mckellar.org>
Content-Type: multipart/alternative; boundary="0016363108735d860004a7d46ae1"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] best practices for storing access token for implicit clients
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 12 Jul 2011 00:31:08 -0000

My guess about no cookies was in the design of implicit client token
passing, the access token is never shared with the server, only the browser
via the redirect_uri's fragment. Once the browser has the token, my question
was about how (or even if) people are storing access tokens between page
refreshes. LocalStorage seemed to fit right but I wasn't sure what holes
that may open up since other scripts may have access to the same local
storage as the page that intercepts the access token.

-Doug Tangren
http://lessis.me


On Mon, Jul 11, 2011 at 7:08 PM, Ian McKellar <ian@mckellar.org> wrote:

> Can't LocalStorage etc be stolen with XSS too? If an attacker gets
> their JS running on the page then the game is up.
>
> Ian
>
> On Mon, Jul 11, 2011 at 7:06 PM, Larry Suto <larry.suto@gmail.com> wrote:
> > Cookies can be stolen by directed XSS attacks.
> >
> > Larry
> >
> > On Mon, Jul 11, 2011 at 3:46 PM, Eran Hammer-Lahav <eran@hueniverse.com>
> > wrote:
> >>
> >> Any cookie? What about a Secure cookie limited to a specific sub-domain?
> >> What are the concerns about cookies? I think this would be helpful to
> >> discuss.
> >>
> >> EHL
> >>
> >> > -----Original Message-----
> >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf
> >> > Of Marius Scurtescu
> >> > Sent: Monday, July 11, 2011 3:15 PM
> >> > To: Doug Tangren
> >> > Cc: oauth@ietf.org
> >> > Subject: Re: [OAUTH-WG] best practices for storing access token for
> >> > implicit
> >> > clients
> >> >
> >> > On Thu, Jun 30, 2011 at 12:45 PM, Doug Tangren <d.tangren@gmail.com>
> >> > wrote:
> >> > > What is the current recommended practice of storing an implicit
> >> > > client's access_tokens? LocalStorage, im mem and re-request auth on
> >> > > every browser refresh?
> >> >
> >> > Both sound reasonable. I think most important is how NOT to store it,
> in
> >> > a
> >> > cookie.
> >> >
> >> > Marius
> >> > _______________________________________________
> >> > OAuth mailing list
> >> > OAuth@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>
>
> --
> Ian McKellar  <http://ian.mckellar.org/>
> ian@mckellar.org: email | jabber | msn
> ianloic: flickr | aim | yahoo | skype | linkedin | etc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.37.1 | Report a Bug | By Email | System Status