IETF Logo Mail Archive

Re: [OAUTH-WG] Flowchart for legs of OAuth

Marius Scurtescu <mscurtescu@google.com> Mon, 04 April 2011 20:45 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 EB7C528C142 for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 13:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 02jfW+nHyr0j for <oauth@core3.amsl.com>; Mon, 4 Apr 2011 13:45:24 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 0436728C12A for <oauth@ietf.org>; Mon, 4 Apr 2011 13:45:23 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p34Kl5tp028185 for <oauth@ietf.org>; Mon, 4 Apr 2011 13:47:05 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301950026; bh=FXFjnKO1lnzDLL7YaDRT7dsTcpk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=LEI5cgVnSpk9EOih7mAhr7J+itpbec9arkpZp6kb93jAtAXrlyU9t6juMhJLmq2nT iDPsAvfjqjIGDhg/dB+UQ==
Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by wpaz21.hot.corp.google.com with ESMTP id p34Kl4wi001417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <oauth@ietf.org>; Mon, 4 Apr 2011 13:47:04 -0700
Received: by gyg13 with SMTP id 13so3070451gyg.41 for <oauth@ietf.org>; Mon, 04 Apr 2011 13:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=km9KFFWxNdZrIhXmx/Z8SZIcVGqtozuESbDld3SdZUw=; b=jDcLg8dD+H2wuZvEM8c9QwXoq8SLfQ5LB42PUY9i/VrrK9XFYjEOzz6gYMh/pqIpc3 JHGQHy2vvD5tIW9vMaIg==
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=yZghdqUeRBQxLc3z2fAous0GKZ1bOnOhKRkDI8plWi2/mCWQsbKqDR3IuOVpARbJQh l6fTgasxDLduTbI/dAow==
Received: by 10.101.54.12 with SMTP id g12mr2680652ank.38.1301950024145; Mon, 04 Apr 2011 13:47:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.34.4 with HTTP; Mon, 4 Apr 2011 13:46:43 -0700 (PDT)
In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <22FB565B-A701-4502-818F-15164D9E201A@oracle.com> <AANLkTimGjiCGk5dpA=YVzq5vDkLR2+caSz=pZ5WiZO9H@mail.gmail.com> <3C84AD7A-F00F-43EC-AAD3-AD2DCFB46B0E@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234464F432BB0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D84F7E2.6090305@redhat.com> <16B9A882-6204-4CBD-B7E3-1D806AF5056C@oracle.com> <4D8A5054.4050006@lodderstedt.net> <BANLkTiniuuRXtkzLubgOjVursVtOGjFe6A@mail.gmail.com> <7616C235-2913-4EE0-A710-F47A4CC9E424@oracle.com> <BANLkTi=XyF25vB6qKX2q8iOpEaZ1yQx9Jw@mail.gmail.com> <65E3F250-5111-4692-BFA7-F5B838E9B41D@gmail.com> <BANLkTik5u5+jjTwnwNCQVyzMux4aMB98yg@mail.gmail.com> <5710F82C0E73B04FA559560098BF95B12505F041B5@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 04 Apr 2011 13:46:43 -0700
Message-ID: <BANLkTi=cKjqnJszxCc3LBS+UkyjH17RC+A@mail.gmail.com>
To: "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Kris Selden <kris.selden@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
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: Mon, 04 Apr 2011 20:45:25 -0000

On Mon, Apr 4, 2011 at 12:38 PM, Zeltsan, Zachary (Zachary)
<zachary.zeltsan@alcatel-lucent.com> wrote:
> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials".
> How can this be done if a client is an application that can't have a client secret?
> The authorization code grant does require client authentication (per section 4.1):
>
> (D)  The client requests an access token from the authorization
>        server's token endpoint by authenticating using its client
>        credentials, and includes the authorization code received in the
>        previous step.
>
> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens.

Right, so something has to give, otherwise there is no solution for native apps.

An authorization server will have to accept clients with no secrets.
Google chose to actually issue secrets even for native apps, with the
understanding that they cannot be guarded properly. It just keeps the
flows and code paths uniform.

Marius

v2.23.0 | Report a Bug | By Email