OpenIDConnect Policy RFC

[alexsnaps]

No description provided.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
15561461	Triggered	GitLab OAuth Application Token	7baefe8	rfcs/0000-oidc-policy.md	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[alexsnaps]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Just to be clear: those are fake 🤦

[jasonmadigan]

nice RFC. I get how it works as a layman, so that's probably a good thing. one comment/q re: cookies

[jasonmadigan]

impl detail, but thoughts on cookie name? oidc connect novice, but unaware of a convention (as opposed to the authz: bearer header)

[jasonmadigan]

thoughts on what has precedence if both present?

[alexsnaps]

tokenSource: would be overridden to e.g. cookie. So either we make it aware of the name to look for (e.g. cookie["auth"]; or make it another config bit (e.g. tokenSourceKey?); and/or with a sensible default (e.g. Bearer?); I'm wondering if this wouldn't best be expressed as CEL ... "somehow".

wrt to precedence, it don't matter, as the user specify what "source" to use.

[eguzki]

Nice API

I feel I cannot spot missing required fields, or unneeded fields until we do some hands on PoC. For instance, not sure the clientID is required field as the client is present in the token (the aud field). The documented AuthConfig example only requires the issuer.

PS: I would pick keycloak as OIDC provider, but gitlab.com is also good, why not!

[alexsnaps]

not sure the clientID is required field as the client is present in the token (the aud field). The documented AuthConfig example only requires the issuer.

Little confused here: what token? The client_id is required to obtain a token, as done here in that same doc

PS: I would pick keycloak as OIDC provider, but gitlab.com is also good, why not!

The plan is to have this working with keycloak too, as well as hopefully most (all?) providers out there. The reason I didn't use keycloak is two fold:

• We already use it in many other cases; and
• It's another dependency for users to install/get running; I wanted a thing that's out there today. I had hoped for github (as that's probably something our users already have an account on), but that's no OIDC provider...

[eguzki]

Little confused here: what token? The client_id is required to obtain a token, as done here in that same doc

I am referring to the JWT token. I cannot tell for sure, as I would need to test it. AFAICT, the downstream user first gets a valid token with provided client_id (following oauth2 workflow for an specific flow type). That (jwt) token is then added to the request. The gateway can download (public) keys (belonging to one SSO realm and not client_id) to verify the JWT and once validated, it can trust on the provided data from the token, one field of which is the client_id. Thus, the gateway does not need any configuration having a client_id to verify JWT tokens. Only the SSO provider and realm.

I could be wrong :)

[alexsnaps]

I am referring to the JWT token. I cannot tell for sure, as I would need to test it. AFAICT, the downstream user first gets a valid token with provided client_id

I get even more confused now! As you say you need a client_id to get to a token. In order to get the authorization code, the user needs to be redirected to the issuer's endpoint and start the flow. That very request, including in the link you provided yourself and then highlighted again above, requires that client_id... So how is it that:

not sure the clientID is required field as the client is present in the token

I must be completely missing the point you are trying to make... 😕

[alexsnaps]

not sure the clientID is required field as the client is present in the token

The point was that it isn't required per se to "merely" do token verify the token, which is indeed correct. But token verification isn't enough and this proposal concerns itself with the entire flow. So the client_id is, if only for that, required to craft the URI to redirect users to in order to obtain said token (and probably check that verified incoming tokens to be the ones expected).

I think this talking point can be considered "resolved"

[alexsnaps]

I started this draft RFC describing how I plan on implementing the infrastructure that would support implementing such OpenIDConnectPolicy, as explained in this RFC.