feat(openid-connect): make session_secret support configurable#8068
Conversation
| | set_userinfo_header | boolean | False | true | | When set to true and the UserInfo object is available, sets it in the `X-Userinfo` request header. | | ||
| | set_refresh_token_header | boolean | False | false | | When set to true and a refresh token object is available, sets it in the `X-Refresh-Token` request header. | | ||
| | session | object | False | | | When bearer_only is set to false, openid-connect will use Authorization Code flow to authenticate on the IDP, so you need to set the session-related configuration. | | ||
| | session.secret | string | True | Automatic generation | 16 or more characters | The key used for session encrypt and HMAC operation. | |
There was a problem hiding this comment.
Should we apply the "16 or more characters" check in the schema?
There was a problem hiding this comment.
Yes, I think it's best to do that. Let me modify it.
| end, | ||
| }, | ||
| { | ||
| name = "sanity (bearer_only = false, user-set secret, less than 16 charactors)", |
There was a problem hiding this comment.
Yes, I have fixed it.
|
Should this also be implemented in |
#6792 (comment) would works for you? |
|
@tzssangglass nice! Following workaround in APISIX helm chart values fixes problem in 2.15.1: configurationSnippet:
httpSrv: |
set $session_secret 0123456789a5bac9bb3c868ec8b202e93; |
Hi all, Now in my values.yaml for apisix helm chart I have: Still I get a "openid-connect exits with http status code 500" error from the openid-connect plugin. What I'm doing wrong? |
Change 'set $session_secret' -> 'set $session_redis_password' , the lua-resty-session lib updated this field |
Description
The current OIDC plugin for APISIX uses
lua-resty-session, which requires encryption of the session, but we do not provide a default secret nor do we allow users to configure it directly.Therefore, according to the implementation principle in
lua-resty-session, if no secret configuration is provided, it will generate one at initialization, yes, one at each worker, and they are all different.When a client uses a short connection or traffic passes through a load balancing component, it may request to a different worker each time, which causes decryption and hash verification failures.
I think if we can allow users to set session secret through plugin configuration, we can solve this problem.
Checklist