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