feat: Close security gaps OIDC implementation to make it work with Okta #2916
Conversation
✅ Deploy Preview for docs-kargo-io canceled.
|
02strich
force-pushed
the
oidc-with-state
branch
from
0062d26
to
c3c484a
Compare
02strich
changed the title
When using PKCE it is recommended to send and validate a state variable to make sure the response fits. While this is not required by the specification, it is recommended, and turns out to be required by some implementations so doing it. Signed-off-by: Stefan Richter <[email protected]>
The offline_access scope is considered to be a security concern when used in web apps by some people. This leads to some OIDC implementations enforcing it to not be used. Anyone who needs it/would like to use it, can configure to add it again. Signed-off-by: Stefan Richter <[email protected]>
02strich
force-pushed
the
oidc-with-state
branch
from
c3c484a
to
f415100
Compare
|
We can take a look at this, but it may be a while. My initial instinct is to avoid this sort of change. Part of the reason we ship with the option to integrate Dex is that it easily corrects for incompatibilities of this nature. For instance, some IDPs don't (yet) support PKCE. Others, like GitHub, don't support OIDC at all. With Dex, resolving these things is a matter of a little configuration instead of code changes. |
02strich
changed the title
|
@krancour happy to wait! In general I would agree with you, though both changes I am making in this PR are security things that Okta just happens to enforce, while the standard just strongly recommends them. I believe they close issues with the implementation as is (I would expect even using it with Dex). Let me know what you think once you have time to look at it! |
The OIDC implementation in Kargo is a good starting point with using PKCE and looking to leverage latest security practices. Unfortunately, it still has some issues that make it incompatible with some providers, e.g. Okta. This PR adds usage of the state variable to add a further data point around call validation, and removes the
offline_accessforced scope as both are considered security requirements by Okta. Neither should create issues for existing customers asstateusage is standards-compliant (and quite common) and the removed scope can be re-added in configuration.Does that seem reasonable?