nebraska icon indicating copy to clipboard operation
nebraska copied to clipboard

[SECURITY] OIDC ID token leaking in ingress controller logs

Open tmsdce opened this issue 2 years ago • 3 comments

Description

When using OIDC, the ID token is sent as a query string parameter in GET requests. Many web servers / ingress controllers log the query string.

Impact

A person with simple read access on ingress controllers pods' logs could retrieve an ID token, possibly granting this person more permissions than needed not only on Nebraska but on various other apps also using OIDC.

Environment and steps to reproduce

  1. Deploy nebraska and expose it through an Ingress (I tested with Nginx)
  2. Watch the ingress controller logs and see the query string parameter being logged :
..."path": "/", "request_query": "id_token=eyJhbG..., "request_length": 3897, "method": "GET"...

Expected behavior

ID Tokens should not be exposed using query string

Additional information

I am not this familiar with the various OIDC authentication flows that exist, so I may be missing something here. Maybe the token cannot be used as is, but I think it's worth checking this out ^^

tmsdce avatar Mar 09 '23 10:03 tmsdce

RFC says SHOULD NOT.

Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers MAY support this method.

https://datatracker.ietf.org/doc/html/rfc6750#section-2.3

acuteaura avatar May 15 '23 12:05 acuteaura

Thank you for reporting this important security concern! You're absolutely right to be concerned about ID tokens being exposed in query strings - this is indeed a security vulnerability that could lead to token leakage through server logs and browser history.

I want to give you a heads up that we have a PR in the works(#1092) that should address this and several other OIDC-related issues. We'll be moving away from passing sensitive tokens through query parameters and implementing OIDC Authorization Code Flow + PKCE.

Backend: Stateless JWT validation only (no OAuth flow, sessions, or client secrets) Frontend: Direct OIDC communication with PKCE and in-memory token storage.

ervcz avatar Jun 27 '25 14:06 ervcz

Thanks for the heads-up @ervcz 👍 I'll keep an eye on the PR

tmsdce avatar Jun 27 '25 15:06 tmsdce