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 <https://github.com/jricher/oauth-pop>
The client requests a token from the auth server using the auth code flow,
nothing special here.
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.
- 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.
- 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.
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.)
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). 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
