The ID Token is not present in the session.

[hiroaki0410]

We are using the Kong and nokia/kong-oidc plugin to incorporate OIDC authentication.
Additionally, we are using lua-resty-openidc and lua-resty-session to store the ID Token in the session.
The session is stored in Redis.

After We upgrade Kong version from 1.5.1 to 2.8.5, the ID Token is not present in the session, causing authentication errors, and we are troubled by this issue.
Our expected value is session.data.id_token=true, but it is session.data.id_token=false, which leads us to believe that the ID Token is missing from the session.
I confirmed I was able to obtain the auth token, get access token and id token in the Authorization Code Flow.

2025/04/16 12:25:35 [notice] 1109#0: *3144532 [lua] openidc.lua:1477: authenticate(): nonce in session : xxxxxxxxxxxxxxxx, client: xxxxxxxx, server: kong, xxxxxxxx
2025/04/16 12:25:35 [debug] 1109#0: *3144532 [lua] openidc.lua:1526: authenticate(): session.present=true, session.data.id_token=false, session.data.authenticated=nil, opts.force_reauthorize=nil, opts.renew_access_token_on_expiry=nil, try_to_renew=true, token_expired=false

There is a similar issue raised, and I suspect that the error might be due to version incompatibility. I would appreciate your opinion on this matter.
#480
#528
#536

The specific versions we are using are as follows:

• Current Old Version
  Kong 1.5.1
  lua-resty-openidc: 1.7.2-1
  lua-resty-session: 2.24-1

• Update Version
  Kong 2.8.5
  lua-resty-openidc: 1.7.2-1
  lua-resty-session: 3.10-1

Thanks.

[oldium]

It seems the code lines do not align with the lua-resty-openidc v1.7.2 tag. Are you sure about the versions or do you have custom modifications of the code to do some debugging?

[hiroaki0410]

@oldium
Thank you for your reply.

Are you sure about the versions or do you have custom modifications of the code to do some debugging?

Yes, I made some modifications to it for debugging purposes.

[oldium]

The breaking factor is lua-resty-session 4.x (since Kong GW 3.2.1.0) and requires lua-resty-openidc 1.8 and updated configuration (like a different way to configure cookie secret). Also, the unmaintained kong-oidc will not work with this. You updated one ancient version to another one, so you should not see this problem.

kong-oidc uses lua-resty-openidc to store the ID Token into the session already and you are saying that you are using lua-resty-openidc with lua-resty-session to store the ID Token into the session. That does not sound correct, right?

[hiroaki0410]

@oldium
Thank you for your reply, and sorry for the delayed response.

The breaking factor is lua-resty-session 4.x (since Kong GW 3.2.1.0) and requires lua-resty-openidc 1.8 and updated configuration (like a different way to configure cookie secret). Also, the unmaintained kong-oidc will not work with this. You updated one ancient version to another one, so you should not see this problem.

I'm aware that there were significant changes introduced in lua-resty-session 4.x, and I have confirmed that the nokia/kong-oidc plugin does not work with Kong 3.4.
When testing on Kong 3.4, I was trying to use the revomatico/kong-oidc plugin instead.

Do you happen to know if the nokia/kong-oidc plugin is compatible with Kong 2.8?
When I initially opened this issue, I was using Kong 2.8.5 with the nokia/kong-oidc plugin, and encountered an error — which prompted me to ask for help.

The authentication flow is as follows:
[Angular App] → [Kong OSS 2.8 (OIDC plugin)] → [Azure AD (OpenID Connect)]

I’ve been investigating the issue using browser DevTools:

• After OpenID Connect login completes, Kong returns a Set-Cookie to the redirect_uri (/callback).
• On subsequent API requests, the session cookie is included in the request header.
• However, the response contains a new Set-Cookie with a different value.

From this, I suspect that although the client is sending the correct session cookie, Kong fails to restore the session and issues a new one each time.

This is what I'm currently trying to debug, but it's been difficult.
If you have any suggestions or notice anything unusual, I would really appreciate your insights.

kong-oidc uses lua-resty-openidc to store the ID Token into the session already and you are saying that you are using lua-resty-openidc with lua-resty-session to store the ID Token into the session. That does not sound correct, right?

As you correctly pointed out, the reason I’m using lua-resty-session is to store sessions in Google Cloud Memorystore Redis. Sorry if that wasn’t clear in my original wording.

[lauer]

I might have the same issue.
I am using this plugin, https://github.com/cuongntr/kong-openid-connect-plugin/, and get ERR_TOO_MANY_REDIRECTS error, because this error, where the openidc.lua does not see the id_token

2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:671: openidc_get_token_auth_method(): 1 => private_key_jwt
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:671: openidc_get_token_auth_method(): 2 => client_secret_basic
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:671: openidc_get_token_auth_method(): 3 => client_secret_post
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:673: openidc_get_token_auth_method(): configured value for token_endpoint_auth_method (client_secret_post) found in token_endpoint_auth_methods_
supported in metadata
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:701: openidc_get_token_auth_method(): token_endpoint_auth_method result set to client_secret_post
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:1609: authenticate(): Authentication is required - Redirecting to OP Authorization endpoint
{"time_local":"22/Aug/2025:05:53:34 +0000","remote_addr":"10.200.200.253","real_ip": "10.200.200.253","http_x_real_ip": "","request":"GET /?state=11caf0d1423d06214c29bd26ffbf240e&session_state=9ed1c1ac-e0
25-4243-a069-fb262a847b3b&iss=https%3A%2F%2Fauth.prod.DOMAIN.dk%2Frealms%2FDOMAIN-internal&code=41074696-fd1f-4bdd-b90c-884b5d47f9da.9ed1c1ac-e025-4243-a069-fb262a847b3b.83690977-717d-4a5e-b63d-5c11d7d14504
 HTTP/2.0","status": "302","request_time":"0.022","remote_user": "","remote_port": "37279","body_bytes_sent": "110","bytes_sent": "994", "request_length": "1274", "connection_requests": "9","http_host": "
SUBDOMAIN.int.DOMAIN.dk", "http_referrer":"","upstream": "", "upstream_connect_time": "", "upstream_header_time": "","upstream_response_time": "", "upstream_response_length": "",
"upstream_cache_status": "", "ssl_protocol": "TLSv1.3", "ssl_cipher": "TLS_AES_128_GCM_SHA256", "scheme": "https", "http_user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KH
TML, like Gecko) Chrome/139.0.0.0 Safari/537.36"}
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:1578: authenticate(): session_present=true, session.data.id_token=false, session.data.authenticated=nil, opts.force_reauthorize=nil, opts.renew_
access_token_on_expiry=nil, try_to_renew=true, token_expired=false
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:555: openidc_discover(): openidc_discover: URL is: https://auth.prod.DOMAIN.dk/realms/DOMAIN-internal/.well-known/openid-configuration
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:561: openidc_discover(): discovery data not in cache, making call to discovery endpoint
2025/08/22 05:53:34 [debug] 1408#0: *2132 [lua] openidc.lua:429: openidc_configure_proxy(): openidc_configure_proxy : don't use http proxy

Environment

• Kong version: 3.9
• Deployment: Official Helm chart on OpenShift
• Plugin kong-openid-connect 1.1.9
• And lua-resty-openidc: 1.8.0.1
• Number of Kong replicas: 1