jens-skribble opened a new issue, #13718: URL: https://github.com/apache/apisix/issues/13718
### Description ### Problem The `openid-connect` plugin seals its session cookie with a key derived from `session.secret`. The `session` schema exposes only a single `secret` and sets `additionalProperties = false`, so there is no way to rotate that secret gracefully. Any rotation is a hard cutover with two concrete failure modes: - Replacing `session.secret` invalidates every live cookie at once, forcing all users to re-authenticate. - In an HA deployment updated instance-by-instance, there is a window where an instance carrying the new secret cannot decrypt a cookie issued by an instance still on the old secret, so requests fail depending on which instance they hit. ### Proposed enhancement `lua-resty-session` 4.x (already used by this plugin) supports graceful key rotation via `secret_fallbacks`: cookies sealed with any secret listed in `secret_fallbacks` still decrypt, while new cookies are sealed with the primary `secret`. Exposing this in the `session` schema would allow a safe pre-seed → flip → retire rotation: - Add `session.secret_fallbacks` (array of strings, `minLength` 16) to the `session` schema. - Add it to `encrypt_fields` so values are encrypted at rest when data encryption is enabled. - Document the rotation procedure in the plugin docs. `build_session_opts` already forwards the `session` table to `resty.session.start()`, so no runtime change is required beyond allowing the field through validation. ### Precedent The `secret` + `secret_fallbacks` pattern is already shipped in the `saml-auth`, `dingtalk-auth`, and `feishu-auth` plugins, including having `secret_fallbacks` in their `encrypt_fields`. This request brings `openid-connect` in line with those. The change is optional and backward compatible: existing configs with only `session.secret` are unaffected. I've opened a PR implementing this: https://github.com/apache/apisix/pull/13702 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
