Hello together,
as far as I know, it is now recommended to use Authorization Code Flow with PKCE in public and confidential clients (draft-ietf-oauth-security-topics-16 - OAuth 2.0 Security Best Current Practice). Unfortunately, the Keycloak-Connect Node.js library doesn’t support PKCE. Are there plans to implement this feature, or do you have any workaround?
Kind regards,
Kevin
What I know Keycloak connect is for the nodejs apps (Express.js, etc so they are not public - they are executed on the server) and not for the SPA.
So I would say PKCE is not a correct requirement for this lib. There are many SPA libs, which support OIDC with PKCE flow (so Keycloak OIDC will be included - used lib really doesn’t need to have a keycloak in the name). I would always prefer OIDC certified library.
Hello,
That‘s right, but we are authenticating our users on the server, to ensure that access tokens etc. are never visible in the frontend. We then save access tokens etc. in a user session on the server and the library uses this information for all subsequent requests. This is all automatically handled by the library. The description of the library says:
This module makes it simple to implement a Node.js Connect-friendly application that uses Keycloak for its authentication and authorization needs.
Hence, i assume that this should be a requirement because in fact you can authenticate via the library.
Auth is done on the server, so there is no need of PKCE/public client.
Okta has good decision tree, which will guide you to choose the best flow for any implementation:
I don’t agree with that. This is some old information I would say. If you look at the current best practices, they recommend to use PKCE in confidential clients. The reason is that it prevents Authorization Code Injection and this could also happen in a server-side confidential client.
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.1.1
There is even a initiative for OAuth2.1 that sums up all current best practices to build one single document that serves as a baseline reference. This document additionally recommends to use PKCE and basically everyone would tell you to use it wherever you can nowadays.
This video shows the Authorization Code Injection Attack, so even Okta is aware of that, so I would assume that the content you have shown is not really up to date.
That is a excellent point 
. But it’s still only a draft (I expect that it will be official good practice in the future). It will need a few years until all libs will implement it. I would say standard is still Authorization code flow. Only bleeding edge implementations may have current support for PKCE - but I’m not aware of any server SP with PKCE flow at the moment. You may find some Libraries, Products, and Tools | OpenID . I also would like to see some right prod implementation, because I see the challenges withPKCE, when app is scaling horizontally. Even Okta’s @oktadev/schematics - npm doesn’t suggest PKCE for express.js app.
This is a community forum, so I wouldn’t expect if anyone from the community will be able to answer when keycloak SP lib will support that draft.
Keycloak devs may be a better audience for this question - you may try dev-mailing list https://groups.google.com/g/keycloak-dev
I would expect that you will be asked to open Jira feature request - https://issues.jboss.org/browse/KEYCLOAK and then you will be waiting and waiting… You can speed it up with own PR, which will implement it.
Alright, thank you very much 
I already tried it at the mailing lists with no luck so far.
