[OAUTH-WG] Recommended token format

Christian Holm <cho@cubitech.dk> Wed, 09 June 2010 20:58 UTC

Return-Path: <christianlholm@gmail.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 3606F3A67E3 for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 13:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.776
X-Spam-Level:
X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
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 7aOuFvZmD8Qr for <oauth@core3.amsl.com>; Wed, 9 Jun 2010 13:58:44 -0700 (PDT)
Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 11DCA3A63C9 for <oauth@ietf.org>; Wed, 9 Jun 2010 13:58:43 -0700 (PDT)
Received: by ewy24 with SMTP id 24so1715615ewy.14 for <oauth@ietf.org>; Wed, 09 Jun 2010 13:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SEuM+Xt8hZnK0fZDVdUMbtjOM8zU65le3fxUmJjLJuE=; b=N0yuNNcL5kWc9rZt6OGEw0ZYXmur47FZbHH1RpErj9B/rI6gYRvLqdLBPmV3Eer1Hv g9bS2FvX7KrBqde+PRsamNurhlm9+uhbcolHVWFbJsNgTY+K/HMk9oV7wETBaR2v1l3y sYVbl2t2mVc5Q0MUL17JbS7vNmyy4P/YQBao8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=J5FhjMbWqc2cFx8q2DQ41+3x1exDWjt4znYf1ARzPAIeki9eGlGykUaamuqf9/W3lu nIueYX2fqHPav7/ZDDMrR3Cn1e8N0OhbK/bH94nX17IKKWQkTEE89o9arTrpyYRmBUgJ hZEOnH7TBxzNmAtZe8PKhvRALXPlD1nnFWeVY=
MIME-Version: 1.0
Received: by 10.213.102.3 with SMTP id e3mr1758132ebo.99.1276117122234; Wed, 09 Jun 2010 13:58:42 -0700 (PDT)
Sender: christianlholm@gmail.com
Received: by 10.213.29.67 with HTTP; Wed, 9 Jun 2010 13:58:42 -0700 (PDT)
Date: Wed, 09 Jun 2010 22:58:42 +0200
X-Google-Sender-Auth: q2hKbpVkKJrvyTw90CTHk0qLQGU
Message-ID: <AANLkTikSRWuuIwPxqbCZqis1e6gQ_Q6Yg5j7gDAVB606@mail.gmail.com>
From: Christian Holm <cho@cubitech.dk>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0015174bea84c363e804889f2bb3"
X-Mailman-Approved-At: Wed, 09 Jun 2010 14:03:18 -0700
Subject: [OAUTH-WG] Recommended token format
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, 09 Jun 2010 20:59:45 -0000

Hi

We are in the process of defining a REST interface for our application, and
are looking to use OAuth 2 as the authentication mechanism. I have read
through the latest specification, and it seems like a perfect fit for our
needs. Our main dilemma is with regard to the format of the access token. As
I understand there are basicly two options:

* Use the token as an "artifact", ie. just a randomly generated string which
is stored centrally. When accessing a resource with the token, the token is
verified by looking it up in the central repository and making sure the
requested resource can be accessed.
* Encrypt the authentication into the token. This way the resource server
can verify the access directly from the token without checking with the
central repository. This is particularly a good idea if the authentication
servers and resource servers are hosted in different data centers.

We would like to go with the second option, but since my cryptology
knowledge is less than could be wished, I have a had time deciding on the
format. I would assume we would have to put the user, the expiry time and
the scopes into the token (perhaps with some random letters in between) and
then encrypt that using f.ex. AES. Are there any recommendations on the
format and encryption method to use? I realize that publicly disclosing the
format could weaken it slightly, so the recommendations will have to be
fairly generic.

Thanks for the help and the excellent work on the OAuth 2.0.

Christian Holm