Re: [OAUTH-WG] Defining a maximum token length?

Marius Scurtescu <mscurtescu@google.com> Wed, 10 March 2010 03: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 992283A6B01 for <oauth@core3.amsl.com>; Tue, 9 Mar 2010 19:25:21 -0800 (PST)
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=[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 nez8c9662QPf for <oauth@core3.amsl.com>; Tue, 9 Mar 2010 19:25:20 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B4BDE3A6AE3 for <oauth@ietf.org>; Tue, 9 Mar 2010 19:25:20 -0800 (PST)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id o2A3POBx021293 for <oauth@ietf.org>; Tue, 9 Mar 2010 19:25:24 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1268191524; bh=9UL0gRdZ1DjGzRc1kq8FkTaPfLM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=uw2MMbXBLz6XlKGHZPO2CCFEttK0nO7y3JSgF9Rz24fDTSdHnNOTvnB5z4m9Plhzj aoGp9CDL9qeHMGFyPqg5w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=X6fM875bnmylBJox1gEmZkL+7QS+6ADB/y6O4fFJsork5ZNgVdeL/tLu1ojkUvjBD 3Es/eZCIm+39VBbkziMhQ==
Received: from gya1 (gya1.prod.google.com [10.243.49.1]) by kpbe16.cbf.corp.google.com with ESMTP id o2A3PM9m013793 for <oauth@ietf.org>; Tue, 9 Mar 2010 19:25:23 -0800
Received: by gya1 with SMTP id 1so296082gya.0 for <oauth@ietf.org>; Tue, 09 Mar 2010 19:25:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.180.12 with SMTP id c12mr440459ybf.144.1268191522244; Tue, 09 Mar 2010 19:25:22 -0800 (PST)
In-Reply-To: <fd6741651003091916o4c3b3a3ao4dc7871ddf7df23b@mail.gmail.com>
References: <fd6741651003091550t5a464496r57aae9a60c516599@mail.gmail.com> <74caaad21003091623i8b7c343jc3bb806fe327492d@mail.gmail.com> <12ED1FAC-B9C6-47C1-AC01-AB33D110EF8C@gmail.com> <68f4a0e81003091824n5453cf4cp151f313de5fd9c5e@mail.gmail.com> <fd6741651003091916o4c3b3a3ao4dc7871ddf7df23b@mail.gmail.com>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Tue, 09 Mar 2010 19:25:02 -0800
Message-ID: <74caaad21003091925x7aeac395uac5ad816c543771e@mail.gmail.com>
To: David Recordon <recordond@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Defining a maximum token length?
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, 10 Mar 2010 03:25:21 -0000

On Tue, Mar 9, 2010 at 7:16 PM, David Recordon <recordond@gmail.com> wrote:
> The challenge is that client developers (who we really want to make
> OAuth dead simple for) will be forced to use less optimal storage for
> tokens (blobs versus shorter and indexable types such as varchars).
> They also won't be able to build any assumptions around token length
> into their database design.  Any DBA cringes when they see the blob
> type for multiple columns within a table (access token and refresh
> token per user).

Why would you index the refresh token column? I think it is enough to
lookup by user id and just retrieve the token.

Also, quite likely that you don't need to store the access token in the
SQL database at all and just make it a session attribute. Not sure what
is reasonable for session data, a large set slows down replication, but
a typical access token should be OK I think.


> Some OAuth servers will have short tokens which a client might
> integrate with first and decide that a varchar(255) is reasonable to
> hold tokens.  They'll then run across a server with longer tokens, not
> realize it, and be confused why their client isn't working when it's
> due to their database silently truncating tokens after 255 characters.

Well, silently truncating data is a different issue altogether.


Marius