IETF Logo Mail Archive

Re: [OAUTH-WG] User-Agent flow and refresh tokens

Marius Scurtescu <mscurtescu@google.com> Wed, 15 September 2010 22:25 UTC

Return-Path: <mscurtescu@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34273A687C for <oauth@core3.amsl.com>; Wed, 15 Sep 2010 15:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.744
X-Spam-Level:
X-Spam-Status: No, score=-105.744 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhPFff7zECuF for <oauth@core3.amsl.com>; Wed, 15 Sep 2010 15:25:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 675573A697F for <oauth@ietf.org>; Wed, 15 Sep 2010 15:25:05 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o8FMPU9o032625 for <oauth@ietf.org>; Wed, 15 Sep 2010 15:25:30 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1284589530; bh=WP0OGef6weCDUybnfZz0+4/BNDc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=kqX4CXiRPPqCyOUTBPr635Pfnf2Jx0yBF/nwOr/PD4jNo77JiVCBlqib4Sy2/Ll55 qF1HlnIWMtISdSwqM9tBQ==
Received: from yxn22 (yxn22.prod.google.com [10.190.4.86]) by hpaq5.eem.corp.google.com with ESMTP id o8FMPRnE009889 for <oauth@ietf.org>; Wed, 15 Sep 2010 15:25:28 -0700
Received: by yxn22 with SMTP id 22so252062yxn.21 for <oauth@ietf.org>; Wed, 15 Sep 2010 15:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=bxszFFvEfpJUDOYA6RJDaQBWNRqTdLGebI7FJdNAqxc=; b=dFHsgrMqajVhSo8lN9qrobuKx6YpzzUoQLMe6C8JvygdBPEznd+b6LDY/EQzcGB1/S bEGidCXLVzdAs7OZOY/Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=M3BmIBQWMNQBe/D2wFc/KyN88gGQ1ybXC3IEJ99ZXNQOKIVs+1/4qMhUVd/Z4rGMQE y1DpVw8lgKF4ZPNwsjVw==
Received: by 10.100.33.18 with SMTP id g18mr2659366ang.68.1284589527167; Wed, 15 Sep 2010 15:25:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.6.6 with HTTP; Wed, 15 Sep 2010 15:25:07 -0700 (PDT)
In-Reply-To: <4C913EE3.90704@lodderstedt.net>
References: <4C913EE3.90704@lodderstedt.net>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Wed, 15 Sep 2010 15:25:07 -0700
Message-ID: <AANLkTikJGDUKCfiPiN_rAVXmbPF0SBN_sKNQFHw6-oqj@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] User-Agent flow and refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 15 Sep 2010 22:25:07 -0000

I don't see why would you use the user-agent flow with a native
application? Maybe the spec should suggest only the web server flow.
The device flow would also work, but that's not part of the core spec.

Marius



On Wed, Sep 15, 2010 at 2:47 PM, Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:
>  I'm wondering whether it makes sense to allow for the issuance of refresh
> tokens by the user-agent flow.
>
> Background of my considerations is the development of applications on mobile
> devices (apps :-)). The draft suggests to either use the web server or the
> user agent flow for the integration of such applications with an OAuth
> authorization server. For sake of user experience, I would expect mobile
> applications to use refresh tokens instead of sending the user through the
> authorization on every application start. I also would assume that the
> mobile client does not use a client secret because it cannot really protect
> it from recovery. Instead, token theft could be encountered by replacing
> refresh tokens with every request to the tokens endpoint.
>
> This scenario is feasable with the web server flow but not with the
> user-agent flow. This is because the later does only support the issuance of
> access tokens. In previous discussions this has been motivated by the weaker
> security (missing client authentication) of the user-agent flow. But as
> pointed out above, the web server flow can (and will be) used w/o client
> secret, too.
>
> So why don't we allow for the  issuance of refresh tokens by the user-agent
> flow?
>
> regards,
> Torsten.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email