[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
- [OAUTH-WG] Recommended token format Christian Holm
- Re: [OAUTH-WG] Recommended token format Torsten Lodderstedt