jricher
commented
4 years ago - You're pretty much spot on here. This is a detail for the webserver-based client. Basically this is a way to share state between the backend and the react-based frontend. Since this is a demo client that's meant to show all the moving pieces, the "pending" data structure stores ALL of the currently running transactions from the client's perspective. It's tied to the current user's session.
- It's more or less a combination of the security aspects of PKCE, authorization code, state, and OIDC nonce all rolled together in one operation.
- This implementation just uses reference-based access tokens because it's not different from OAuth2. The internal format for this token can be anything, including a JWT, and it's opaque to the client. The RS would need a way to interpret it either by looking it up at the AS or by reading it directly in the token. This demo server doesn't do a lot with the RS side of things because there aren't a lot of changes there, at least not yet.
- Binding keys to access tokens is something that still needs to be sorted out. Using the client's own public key, like DPoP, is pretty straightforward. But I think we can also have the AS issue key material, including symmetric keys, like the old OAuth PoP Architecture and Key Distribution documents allowed for. I think there's still work to do to figure out what to do there. It's probably not clear because the implementation right now only does bearer tokens, but the idea was to allow both bearer and key-bound access tokens, and probably other kinds of access tokens in the future with different forms of proofing and presentation.
fimbault
Hello Justin,
This is not an issue as such, but more a documentation question. Your feedback would be most welcome as we can't really figure out what is intended from what we've seen.
We're just starting to prototype a new opensource implementation (client and server) to really get it, before we can make suggestions to the standard. Would also like to check compatibility with your implementation (so far, it doesn't seem to take into account a generic client callback uri, and tries to use http://localhost:9834/api/client/callback/).
Anyway, most of it is clear but I've got a few important questions to clarify (on the redirect with callback flow) :
1) Pending : it seems that you use it to log what is going on, and also as a simplified state machine to check the session (session.setAttribute("_pending_approval", pending)). It's probably an implementation detail but how do you see the purpose of that pending state ? Is it also supposed to be used to control which URLs one can access at one point in time (e.g. disable an interact endpoint)?
2) Continuation of transaction : when described at the end of the interact (before token is issued), am I right if I understand that as a PKCE equivalent?
3) Token and interaction with the RS : here I'm confused, tokens are just basic handles (with a random value). Seems fine for transaction handles (as described in https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-9), going back and forth between the client and the AS.
But what about the real access token to be used with the RS? Like a JWT or a JWS? Something with a header like : { "typ": "JWT", "alg": "RS256", "kid": "mykey" }? More generally speaking, how do you see the flow with the RS? Is there an example?
I don't really get : "The associated key may be one of the public keys the client has proved ownership of when talking to the AS during this transaction, or it may be a key generated by the AS and handed to the client." The last part of the sentence is fine (if it's generated by the AS), but how would I use the client public key here ?
I guess that's a key point to understand XYZ but I'm not sure I get it, from the available documentation or the current implementation.