nginx-openid-connect icon indicating copy to clipboard operation
nginx-openid-connect copied to clipboard

Request For Enhancement - encrypting values of cookies using a shared secret

Open nergalex opened this issue 8 months ago • 0 comments

Hi,

In order to host nginx-openid-connect based instances in a F5 Distributed Cloud (XC) Customer Edge (site) multi-cluster (virtual site), as descibed in this solution, nginx-openid-connect should evolve to do not use shared sync zones. Because, each XC site has a different DNS domain.

An evolution could be to move from a shared state model to a shared nothing model by modifying the nginx-openid-connect project to:

  • Remove the keyval zones currently used to store ID Tokens, Refresh Tokens, Access Tokens.
  • Instead, these tokens, will be stored in cookies return to the client, replacing auth_token cookie (and friends).
  • The cookie will be encrypted by NGINX(njs) using a user-defined shared secret (in the nginx configuration) before dispatch so that only NGINX (njs) may read the actual token within each cookie.
  • We may optionally compress the tokens prior to encryption also if size is a concern (also with njs).
  • We receive these cookies from the user ever request just like auth_token cookie.
  • Remove/swich out these keyval defined variables to now be js_set functions, which lazy decode each token as and when needed using the shared secret.

As an aside, this method of encrypting values of cookies using a shared secret is somewhat similar to how NGINX App Protect implements enforcer cookies without shared state (beyond the encryption / signing key).

The only shared dependency in this solution is the encryption key, which can be static / semi-static, so there is no need longer a need for zone-sync.

nergalex avatar Feb 24 '25 13:02 nergalex