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 <jric...@mit.edu
<mailto:jric...@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:
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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
