Repository navigation
Replies: 4 comments 2 replies
|
I am curious what Keycloaks plans are on direct access grants in the future. |
|
It might be interesting to have a look at this draft then: https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps/
There is already an ongoing discussion here: #25014 |
|
Maybe points 1 and 2 could be implemented easily without any impact on existing configurations. |
|
I'm strongly advocating for NOT removing Direct Access Grants because we heavily depend on it to authenticate service accounts that use our REST services with Basic Authentication. Moving the complete customer base (mostly financial sector) to another mechanism is a journey that would take several years. |
|
I agree that ROPC should really suffer a terrible death; it makes little sense as a way to interact with an IdP, especially these days. That being said I also fully appreciate that many have decided to use it regardless, hence removing it completely is not something that will happen anytime soon. In terms of your proposal:
|
|
Yeah definitely agree with all that. I originally wrote this ~2 years ago, so certainly some things and thoughts for myself have changed. It is unrealistic to think the ROPC code itself would be dropped from Keycloak - too many legacy usages and use cases, and sometimes the risk is acceptable. Admins ultimately have to be able to make that decision. My original intent with turning off ROPC by default as a feature (at least for new instances) was to just help strictly guide new admins/users of Keycloak towards best practices - its easy to ignore messages that say "Hey, this is a bad thing to do!" - if they literally can't do it it might give them pause to think about what they are doing and why that particular feature isn't so easily available. But I think in lieu of that, any auditing / security health kind of functionality like you mention in your 2 would be great. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The Problem
Today, Keycloak supports ROPC flow as mentioned in the OAuth2 specification. It would be nice to see Keycloak deprecate this functionality and guide users against using it, and even in some cases make it so that it could be turned off entirely if desired. OAuth 2.0 Security Best Current Practice states very clearly that ROPC should not be used, and I often wonder if the user base is aware of that fact. There are also some folks asking about OAuth 2.1 support in Keycloak, which removes both ROPC and implicit flows entirely.
Proposal
There are a few things I feel could be done to move Keycloak forward on this front and I wonder what else the maintainers and community thinks we could do to guide users away from using ROPC.
Stop setting "Direct Access Grants Enabled" checked by default on the Admin UI when adding a new OIDC client. ✔️ Done via - Issue 30226
Adding a warning symbol or similar callout on the Admin UI that this is not a recommended setting when it is used.
Feature flagging ROPC as a feature - disabling functionality and no longer advertising on the OIDC Well Known Endpoint as a supported grant type. This would allow users to opt-out of ROPC in their deployments altogether. Client policies could fit here in some manner, but it would feel better if there was no possibility of the flow being used at all because the code path was explicitly off. Client policies also does not provide the ability to keep clients from discovering the grant type being supported.
Eventually moving ROPC feature as "off" by default
Removing ROPC outright from the code base- ❌ - Not likely to happen given MANY long lived edge cases and legacy needs still fulfilled by ROPC.Some considerations
I can see some quick, positive gains with 1-3 but 4-5 are certainly longer term items. Item 5 in particular has some other implications as I think some of the integration tests today rely on some level of ROPC to generate tokens. I think there are also items around
kcadm.shtype scripts where support for device auth or some native app authorization code flow could be added as an authentication option to replace ROPC where service accounts would not fit the use case?All reactions