[OAUTH-WG] Wrapping access token and codes

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 06 November 2014 12:11 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28F1A1B79 for <oauth@ietfa.amsl.com>; Thu, 6 Nov 2014 04:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjNPK_5K66CP for <oauth@ietfa.amsl.com>; Thu, 6 Nov 2014 04:11:51 -0800 (PST)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACECC1A1B6C for <oauth@ietf.org>; Thu, 6 Nov 2014 04:11:50 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id b13so1002259wgh.25 for <oauth@ietf.org>; Thu, 06 Nov 2014 04:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MVP0vezDpQQPUpTDwAxkIUSz66WGGvc+BMxKwXHZVNw=; b=hfKys2VLtGsnzozX52Al7uojT+4p0T+nexe35zjFyxpbOnipW1fbQpkEfqV34nQZj8 j13VjBP7LDOAkTB0IWSn+lsX0yF9l3Kl4GkWfKG4KWDhWilytvpdswHkzRPQsJP3b9x/ nu94byUoBAdOb+mxs93ZJS+XrFrERISqmPND25vH81w+D5VrqY3/iEnFAWcD2U6GF4Oh q5T2YahPGN1dt+UUtS9wnltdaZaMThvN0Lt47b99ocx7oVTosJBem5CDZAvTjpQCi+hL abKcneEjZKQSnfNf2F2ciNtUrDMYiFBpHJIrHisVP8y7oOFw3Q1ueWjQlHVsa5HwybnY COLg==
X-Received: by 10.194.94.9 with SMTP id cy9mr4857867wjb.117.1415275909432; Thu, 06 Nov 2014 04:11:49 -0800 (PST)
Received: from [192.168.2.7] ([109.255.82.67]) by mx.google.com with ESMTPSA id fq1sm19285778wib.12.2014.11.06.04.11.47 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Nov 2014 04:11:48 -0800 (PST)
Message-ID: <545B6582.2030505@gmail.com>
Date: Thu, 06 Nov 2014 12:11:46 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <545760D7.3090900@surfnet.nl> <CAOyugYZnEz-uhA9M-1bx1m9cVf0UG8cH7aB+-skHiKmwh0Aikg@mail.gmail.com> <0FBFB9F2-508B-495B-9075-E664351C8D96@mitre.org>
In-Reply-To: <0FBFB9F2-508B-495B-9075-E664351C8D96@mitre.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/72F_jPqFaHfYJC5BPXjiRqt7GEI
Subject: [OAUTH-WG] Wrapping access token and codes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 06 Nov 2014 12:11:52 -0000

Hi

Does it make sense to consider supporting an access token or code 
wrapping as part of the standard OAuth2 responses ?

For example, if a client has registered its public key with AS then say 
the access token response would contain the regular

{"access_token":"1234345"}

except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque 
token with a client's public key being used. Or a direct key encrypted 
token if the client and the server only share the client secret 
allocated to the client during the registration.

The net result is that only the registered confidential client would be 
able to extract the actual opaque access token. The response would 
actually be

{"access_token":"1234345", wrapped:true}.

I definitely plan to use this approach as a simple mechanism for making 
a safer distribution of mac keys as part of access token responses; but 
IMHO it can be handy for minimizing the possibility of the 
access/refresh tokens or codes being intercepted...

Sergey