Re: [OAUTH-WG] OAuth PoP Implementation

[Justin Richer <[e-mail]>]

Hi Erik, responses inline.

On 2/4/2016 4:20 AM, Erik Wahlström wrote:
> Hi,
>
> 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 <[e-mail] 
>> <mailto:[e-mail]>> 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:
>>
>> https://github.com/jricher/oauth-pop
>>
>> 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.

Should be generally identical to bearer tokens, so that's good to hear. :)

>
>> 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.

Yeah, it's a little bikeshedding but I think "access_token_key" is 
clearer and the WG should go in that direction. It'd be a trivial change 
for my code to change to "key" too if we went that way, it's syntax.

> I’ve actually have a problem naming a PoP based access token. Is it a 
> PoP token or an access token?

PoP tokens really have two parts: the access token itself, which is 
analogous to the bearer token, and the key associated with it. That's 
part of why I went with "access_token" and "access_token_key" above. I 
would still consider a PoP token a kind of 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.

I think we should be consistent about this, and I think we should use 
objects where possible (IE, where we're already speaking JSON) and 
strings were not (IE, where we're speaking www-form-encoded).

>
>
>>  - 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.

Makes sense, and I want to explore the implications of client-supplied 
keys on my implementation too. Just haven't gotten there.

>
>>
>> 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
>
>

Yes, exactly like that.

>>
>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>