WIP docs/proposal: submit poll based binding#157
Conversation
c6114df to
bc0e163
Compare
bc0e163 to
5a368fc
Compare
| // +kubebuilder:validation:MinLength=1 | ||
| ClusterID string `json:"clusterID"` | ||
|
|
||
| // sessionSecret is an ephemeral secret that is valid for this session only. |
There was a problem hiding this comment.
Is there an advantage to the back-end generating the session secret?
There was a problem hiding this comment.
yes, as it is the only trusted source for the secret. clients could be compromised.
| - **MUST** The authentication URL includes a session ID query parameter `s` that was returned from the backend. | ||
| - **MUST** The authentication URL includes a base64 encoded SHA256 HMAC signature query parameter `h` that is generated on client side. | ||
| The signature signs a payload consisting of all request parameters, the host, scheme, and request body. | ||
| - **MUST** The authentication URL includes a random nonce `n` that is generated on client side. |
There was a problem hiding this comment.
n is missing in the illustrations.
There was a problem hiding this comment.
it is not really necessary for understanding the flow, it is a non-cryptographic unique number, could even be a counter.
| ### Reference implementation | ||
|
|
||
| The existing reference implementation needs to be extended to be able to handle the above described polling based approach. | ||
| Most notably the existing implementation needs to maintain session state. |
There was a problem hiding this comment.
What does the session state contain? Probably
- session secret
- nonces used
- cluster id
- session id
There was a problem hiding this comment.
used nonces are not necessary, they are just salting the request.
|
@lhaendler thanks a ton for the review! 🎉 I'll continue enhancing this in the next days 🎉 |
|
@lhaendler @sttts fyi: I'll rework this and will try to submit a new version of the proposal as I believe the process can indeed reuse OAuth device flow instead reinventing it. |
No description provided.