Re: [OAUTH-WG] OAuth PoP Implementation

Erik Wahlström <> Thu, 04 February 2016 09:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC57A1A219C for <>; Thu, 4 Feb 2016 01:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e2ji_tdUrozt for <>; Thu, 4 Feb 2016 01:20:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50DCE1A219B for <>; Thu, 4 Feb 2016 01:20:53 -0800 (PST)
Received: by with SMTP id j78so31889050lfb.1 for <>; Thu, 04 Feb 2016 01:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=E8Mg8nNz+BtPT0oBLY760hO/2wDNpsY9fVx/GcFO+Y8=; b=aRsEhrjgUCq9JccKdxRPf2n6mpQllmESSHb7lozOMXD15NcXWW3st1sR36rtFcp5HS ucA7TseZrd2ZvMO66BdeAIepnJFkk919RMv57O2yjjxtlbkSbmkuS7m3fNhcI545eN7h hmSgsueB3vaImWJjVabC7QtwS9Solkamo4OshzM0PaER+6BwJG4DhTiSv9iSMiSpp6to fhy4Fh8fP+FCQ75u1zc2ukhubVlF5hzpcyVlGUb6XQ1MvrsZPkUA4Js8gDhjX//7Meit 1iCfZe/sApk9FkAc/pprNVB13roe4P9vmSW6Ow6KCWBOxuH7cb/lKmljvFPuDl6ABU9o M/nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=E8Mg8nNz+BtPT0oBLY760hO/2wDNpsY9fVx/GcFO+Y8=; b=XA2PWLyB7/N5R1E97wDwpGZ7Nc7rPPoQ6gtF6ueRUdq7Kx2OfCU+KOd67ereSJXjCZ +Vnk+G2ktY9NCgUGtlsJ6H6Qm1204xGy0AYaPdqeblg3HK2f1iEIvTbERKiNWGOT02s4 DmQEexJtTj2/RXdO7T6nMppRbDFWYwaIoS2bYO8aWiM1apXhkLpafTSy8Tq/BD1AcqyG b3qs8/aTt/f2xMw/UNUEynbECd5dVdG4R173H23jZDod3oH0FO46nbOXobwd4mGvBgwO kfBdcWo3QD9v6TmQDg+wJI+bY6MpahLV5Vm3gHpw+AViCm4VLI4p58ieDwjuY6+XJrdN i3nA==
X-Gm-Message-State: AG10YOQXm328B/WNNCSWGwlCU1H07twbc8U/NyALv+SM3TsXUggX1wzUQ6FYhCGBo4QJKg==
X-Received: by with SMTP id k39mr3030384lfi.152.1454577651443; Thu, 04 Feb 2016 01:20:51 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 87sm1454618lft.20.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Feb 2016 01:20:49 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_95CFA0DA-0449-4EF2-BFFA-B72975A50119"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Erik Wahlström <>
In-Reply-To: <>
Date: Thu, 04 Feb 2016 10:20:49 +0100
Message-Id: <>
References: <>
To: Justin Richer <jricher@MIT.EDU>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] OAuth PoP Implementation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2016 09:20:56 -0000


Good work Justin.

I’ve also implemented (parts) of PoP tokens for the ACE WG oauth2 draft and made a lot of the same assumptions. 

See below.

> On 03 Feb 2016, at 23:47, Justin Richer <jricher@MIT.EDU> wrote:
> Hi Everyone,
> I recently decided to put together an end to end implementation of at least part of the proposed OAuth specs. I haven’t seen any other implementations of the whole system, so I wanted to see how viable this whole idea really. It’s done in Node.js (using Express.js) and it’s on GitHub here:
> <>
> The client requests a token from the auth server using the auth code flow, nothing special here.

I use client creds but nothing special there either.

> The AS generates a random-value access token and a 2048-bit RSA key in JWK format. It sends the keypair to the client alongside the token. This step varies from the pop-key-distribution draft in the following ways:
>  - Parameter name is “access_token_key” instead of just “key”, partially to allow us to redefine keys for other tokens like refresh tokens in the future.

My implementation uses “key” but it would be a quick change. I’ve actually have a problem naming a PoP based access token. Is it a PoP token or an access token?

>  - Key is returned as a JSON object, not string-encoded. I think we should use the fact that JWK is JSON in the response from the token endpoint. This makes it difficult for the implicit flow, but we can define a separate encoding for that flow. I don’t see a good argument for crippling the token endpoint with the limitations of another part of the system.

Looking through my code I use a string in the token response, but actually use a object in the request if it’s a asymmetric key that should be bound to the token and the client generates the keys. Will change to object in the response.

>  - The AS doesn’t return an algorithm, I should probably add that to my implementation though.
>  - The AS doesn’t let the client pick its keys or algorithms on any part of the process but always issues the same key type. I understand this to be a valid (if not very friendly) interpretation of the spec.

I have that as a config on the AS for the RS.

> The client takes this token and key and makes a JWS-signed object out of them. It adds a few bits about the request, but doesn’t do the normalization and hashing of query parameters and headers yet. That’s an important bit that still needs to be implemented. 
> The client sends the signed object (which includes the token) to the RS over the authorization header using the “PoP” scheme name, mirroring bearer tokens.
> (Note: I’ve also updated the HTTP signing draft to incorporate the necessary changes above, which were discussed in Yokohama. That should be posted to the list already. It’s a lot of rewriting, so please check the diffs. Yes, I’m aware that the chairs have stated their intent to replace me as editor for the document, but I haven’t heard any communication beyond that original announcement so I felt it prudent to publish the update anyway.)

Will read through changes asap.

> The RS parses the signed object out of the header and extracts the token. The RS introspects the token at the AS to get the key (note that it doesn’t send the whole signed object, just the access token itself).

Same here.

> The key is returned in the introspection response as “access_token_key”, parallel with the response from the token endpoint. It is a JSON object here, too (not encoded as a string). Whatever we decide for the token endpoint response we should stay consistent for the introspection response.

Just so that I follow correctly, do you return something like this (but with access_token_key).

	"active" : true,
	"key" : {"kty”:”…

/ Erik

> The RS uses the key to validate the JWS’s signature. The RS uses the other bits from the introspection callback (scopes, client ID, stuff like that) to determine how to respond, like with bearer tokens.
> The RS responds to the client like in a more traditional OAuth request.
> It’s my hope that this simple implementation can help us move the conversation forward around PoP and help us make sure that what we’re implementing is actually viable. 
>  — Justin
> _______________________________________________
> OAuth mailing list