Forward OIDC id_token to backends

[brianehlert]

Enhance the OIDC Policy object to include the option to forward the ID token to the backend.
This would result in two token forwarding options: one for the access token (existing) and one for the ID token.

The proposal for the Policy change would look like this:

spec:
  oidc:
    clientID: nginx-plus
    clientSecret: oidc-secret
    authEndpoint: https://idp.example.com/openid-connect/auth
    tokenEndpoint: https://idp.example.com/openid-connect/token
    jwksURI: https://idp.example.com/openid-connect/certs
    accessTokenEnable: true
    idTokenEnable: true

This is implemented using the OIDC reference implementation and involves saving the oidc_id_token and adding it to the headers for the backend servers to intercept.

Similar to the PR that enabled access token: #3474

What needs to be forwarded appears to be the $session_jwt from here: https://github.com/nginxinc/nginx-openid-connect/blob/74948ce512e199ca6189fe75bbb2b52fcdbd0148/openid_connect_configuration.conf#L95

[brianehlert]

@shawnhankim since you contributed Access Token forwarding, are there other considerations or details that need to be added here?

[shawnhankim]

@brianehlert
Thanks for the question.

Regarding the idTokenEnable:

• Let me know if you want me to take a look at this feature.

Regarding other features for the OIDC, you could consider the followings:

• endSessionEndpoint

  • https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout
  • If we don't provide this feature, NIC users must develop this to fully log out from the IdP.

• Customizable params

  • As-Is: additional custom query params of the authEndpoint is supported.
  • To-Be: additional custom header/query params support for several endpoints (e.g., logout, token).
    • NIC can enhance the interoperability and support multi IdPs based on this customizable params.

• sessionCookieValidationEnable:

  The current RP implementation is using $request_id generated by the NGINX for the session cookie. This wouldn’t validate to which client the session is created after successful token exchange with the IdP. So possibly anyone who holds the session cookie could access backend from any client (Browsers or Command-line).
  
  AC:
    - 1. While generating the session, instead of using the $request_id of NGINX, generate $session_id using the client’s agent (browser name or command-line) + client-id + client ip and hash it using SHA 256 algorithm.
    - 2. Optional : Add time stamp (hh:mm) to the hashed session_id.
    - 3. Upon the session cookie is presented by the client every time, validate it with k/v store for the match to retrieve the token(s) and also in parallel, process the step 1 once again to see supplied session by the client same as newly generated session; If no match; invalidate the existing session and invoke the new RP flow to get user authenticated.
    - 4. This feature would be available by default and customer can choose NOT to process Step 3 using configuration.
  
  Assumption:
    - Users who receives the session_id on their client’s user agent can't be using the session by manually copying it in to another client’s user agent.
  

• userInfoEndpoint (Optional):

  • https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
  • This can be used for the scenario where the frontend app needs to show or edit user information using access token in detail.

• Multiple IdPs support per host

  • As-Is: one IdP support per host
  • To-Be: X IdPs support per host (customers can choose one of IdP applications per host)

Please feel free to let me know if you need any questions or helps further.

[brianehlert]

If you would like to look into idTokenEnable we would be happy to take the enhancement.

Just to be clear, this project takes the OIDC reference implementation as is, we don't fork it. We copy it forward as it changes (or at least try to remain in sync). I mention that as I am interpreting the session cookie comments as something for this project to implement and we would expect the OIDC Reference implementation to be providing that capability.
And the only thing that would need to happen in this project is to expose the setting. Am I misunderstanding your comments?

[shawnhankim]

Just to be clear, this project takes the OIDC reference implementation as is, we don't fork it. We copy it forward as it changes (or at least try to remain in sync). And the only thing that would need to happen in this project is to expose the setting

• Yeah, we only need to expose the setting and add 1 additional directive to forward OIDC id_token to backend in the config file without changing of the OIDC reference implementation.
• Let me take a look in to the idTokenEnable.

I mention that as I am interpreting the session cookie comments as something for this project to implement and we would expect the OIDC Reference implementation to be providing that capability.

• I am going to donate this feature into the NGINX Plus OIDC reference implementation when ACM starts private APIs.
• So, your expectation is correct.