You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: this issue relates to the Web workflow, not the API/CLI workflow.
Cloud-Gate (can) have a shared secret which is used to sign JWTs, so that reloading the page is fast since you have a valid JWT. Support fetching this shared secret from AWS Secrets Manager.
Without a shared secret, Cloud-Gate generates a new secret at startup and uses a fixed cookie name for that secret. This leads to two different undesirable scenarios:
In an environment with a single Cloud-Gate instance, every time it restarts the old cookies are invalidated and thus Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, which slows down the user experience.
In an environment with multiple Cloud-Gate instances (required for HA), every time a user is bounced to a different instance (which can happen every time they reload the page), their cookie will be invalid (because each Cloud-Gate instance has a different signer key but they share the same cookie name), and again Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, slowing down the user experience (and dropping more cookies in the users web browser).
By using a shared secret stored remotely, the best user experience can be provided regardless of restarts, redeploys or switching between Cloud-Gate instances. However, it requires more infrastructure setup. Some simpler alternatives are discussed below:
(1) can be resolved by writing the generated secret to the file-system, so that a restart of Cloud-Gate does not effectively invalidate cookies. Redeploying instances will of course invalidate cookies if there is no external storage for the secret
(2) can be resolved by using a cookie name which is unique per instance (i.e. by folding in the hostname, IP address, MAC address)
Combining (1) and (2) yields a better experience, although redeploying instances will still result in new cookies and hence a slowdown each time users happen to hit a new instance.
The text was updated successfully, but these errors were encountered:
Note: this issue relates to the Web workflow, not the API/CLI workflow.
Cloud-Gate (can) have a shared secret which is used to sign JWTs, so that reloading the page is fast since you have a valid JWT. Support fetching this shared secret from AWS Secrets Manager.
Without a shared secret, Cloud-Gate generates a new secret at startup and uses a fixed cookie name for that secret. This leads to two different undesirable scenarios:
In an environment with a single Cloud-Gate instance, every time it restarts the old cookies are invalidated and thus Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, which slows down the user experience.
In an environment with multiple Cloud-Gate instances (required for HA), every time a user is bounced to a different instance (which can happen every time they reload the page), their cookie will be invalid (because each Cloud-Gate instance has a different signer key but they share the same cookie name), and again Cloud-Gate will have to re-do the OAuth2 workflow to Keymaster to re-authenticate the user, slowing down the user experience (and dropping more cookies in the users web browser).
By using a shared secret stored remotely, the best user experience can be provided regardless of restarts, redeploys or switching between Cloud-Gate instances. However, it requires more infrastructure setup. Some simpler alternatives are discussed below:
(1) can be resolved by writing the generated secret to the file-system, so that a restart of Cloud-Gate does not effectively invalidate cookies. Redeploying instances will of course invalidate cookies if there is no external storage for the secret
(2) can be resolved by using a cookie name which is unique per instance (i.e. by folding in the hostname, IP address, MAC address)
Combining (1) and (2) yields a better experience, although redeploying instances will still result in new cookies and hence a slowdown each time users happen to hit a new instance.
The text was updated successfully, but these errors were encountered: