Repository navigation
Node.js adapter deprecation #9818
Replies: 23 comments 32 replies
|
To put in my two-penny worth: openid-client is certified, exposes a framework agnostic API, and supports Passport.js out of the box. By the way, did you plan to notice users of this deprecation ahead of time on the npm.js page and deprecate the package? |
|
Thanks, have you tried openid-client yourself and have some experience with it (with or without Keycloak)? |
|
Mentioning the deprecation on npm.js and deprecating the package on npm makes a lot of sense, and we should definitively do that. |
|
The Node.js adapter for Keycloak had a quite high level API for Middleware/Connect style framework. It was fairly simple to protect routes, to enforce permissions, or to access tokens. From what I see, openid-client exposes a lower level API, closer to the actual OIDC specifications. I wouldn’t use it as a drop-in-replacement. However, in combination with Passport.js, it might well provide a similar experience and ease of use. Unfortunately, I haven’t used it so far, since I integrated my projects with the Node.js Adapter. Actually, I wrote a plugin to adapt it to Fastify few weeks ago, just before I read the deprecation notice (glad I didn’t spend more time on it)! |
|
I don't know if this is the place to mention this, but when we no longer support adapters it will make using keycloak harder. I think it will be harder to maintain and have good examples of how to get started with keycloak |
|
This is the perfect place to mention this. However, the problem is really down to capacity, and the broad spectrum of adapters that are needed. For example having a great Node.js adapter (which we don't atm btw) is very little help to a .Net or Go developer. Rather than focus our effort on developing adapters for a small set of users, we should rather focus the effort on documenting how to get started with third-party libraries, and also integration tests with third-party libraries to make sure Keycloak can be integrated with a wide-range of different frameworks/languages/etc. In reality the only adapters we have that have wide usage is the WildFly adapters, other adapters like Node.js does not have anywhere close to the adoption it would require to put the effort into creating a full-fledged and well maintained adapter. In addition such an adapter should be portable cross different OIDC providers, and not have a lock-in with Keycloak directly, and we really don't have capacity to deliver and test our adapters with other OIDC providers. |
|
I would like to add that, as a Keycloak adopter, I loved the comprehensive documentation (and its easy access level), examples and the ease of use of the system as a whole. Under 5 minutes, I could get my hands on a fully working containerized instance. It was as equally fast and easy to integrate a simple test application and play with different options and situations. So, this is really much wanted: supportive migration guides, comprehensive documentation and up-to-date examples. |
|
I share the same perspective as Stian. I see some reasons for deprecating the Node.js adapter:
|
I especially like this last point, Bruno. So without our own adapters, we need to put effort into quick starts using third party open source adapters. Then we get involved in the ongoing development of those adapters. IMO, that's definitely the way to go. But it leads to an extremely important question. How much resources are we willing to put into this effort? I could see this as a full time job for one developer. And it would be money well spent to make sure that we have outstanding quick starts and a large suite of recommended, well-tested, third party adapters. |
|
I do not wanna say something that feels against the flow but right now I am trying to do it in openid-client but the API is very poor compare to keycloak-connect and I have to investigate how to do it in openid-connect. Any idea on where I can find some examples to help me on that note? |
|
@kasir-barati read this blog post if it can help you : keycloak-express-openid-client |
|
I am all in favor of deprecating this, considering we realistically cannot keep maintaining this. Also since there are better options available that are open-source and easy to use. That said, I think we should clearly communicate that this is deprecated by adding it to the readme of the repository and perhaps lock some things down on the repo. Also I believe that one of our strengths was the comprehensive documentation we had, and perhaps we should invest in some community guides with common frameworks and libraries to help folks get started. |
|
I also found the keycloak-connect adaptor very easy to use and was worry about the barrier to entry. Gave openid-client a go, found it difficult to use/understand on its own. In the ended using it with passport.js intergration. Got it working in the end and I have a blog https://dev.to/austincunningham/keycloak-express-openid-client-3mmg for anyone who is interested. |
|
Are there plans to integration test any of the recommend adapters with Keycloak? |
|
That's the plan yes |
|
Is it also in the plan to support adapters for mobile applications such as https://appauth.io/ ? |
|
@stianst can we have a docs update in the recommended way of using openid-client to secure nodejs bearer clients ? Honestly, I didn't see any straightforward example into doing that on node, and most of the examples in the openid-client library seem to be biased towards confidential clients. |
|
I think this issue is limited to the node.js adapter versus client side. But would like to confirm that as from the node-openid-client docs - |
|
I spent some time this week looking at oidc clients. From what I can see openid-client is the most widely used client (based on weekly downloads), is well maintained with a shallow dependency tree, and has no red flags from my review so far and run of npcheck. The one area of minor concern is that it would be better if the project was part of a foundation and/or had regular contributors from multiple organizations versus a single maintainer(that is what it looks like based on git commits), but I don’t think any of the alternatives have that either. It was relatively easy to integrate into one of the existing Keycloak quickstarts using common practice for Node.js (passport) and seems to work as expected. The updated app.js for the example that supports either bearer or oidc is in https://drive.google.com/file/d/13-Y3X2CaTGFs3xkYkhipJ6pFWrJczPtB/view?usp=sharing I’m planning to get some additional feedback from the RH/IBM Node.js reference architecture team, the internal RH Node.js team and some of the internal chat rooms, but so far I think openid-client looks like a good candidate. It might also be good to take a look through the code once the decision is made as well. More details of what I looked/considered in - |
|
Could you please make the drive files public ? |
|
Attaching the file which I probably should have just done from the start. const express = require('express');
const session = require('express-session');
const bodyParser = require('body-parser');
const passport = require('passport');
const BearerStrategy = require('passport-http-bearer');
const { Issuer, Strategy } = require('openid-client');
const cors = require('cors');
// for use in bearer example
const authConfig = {
issuerURL: 'http://localhost:9080/realms/master',
clientInfo: {
client_id: 'service-nodejs',
client_secret: 'Nf1ICCZi1rIDClgv8r1LlVxhS6w3T2VT',
response_types: ['code']
},
type: 'bearer',
createStrategy: function(authConfig) {
return new BearerStrategy(function(token, done) {
authConfig.client.userinfo(token).then((userInfo) => {
return done(null, userInfo);
});
})
},
passportOptions: { session: false }
}
/*
// for use in oidc example
const authConfig = {
issuerURL: 'http://localhost:9080/realms/master',
clientInfo: {
client_id: 'service-nodejs',
client_secret: 'Nf1ICCZi1rIDClgv8r1LlVxhS6w3T2VT',
redirect_uris: ['http://localhost:3000/auth/callback'],
post_logout_redirect_uris: ['http://localhost:3000/auth/logout'],
response_types: ['code']
},
type: 'oidc',
createStrategy: function(authConfig) {
return new Strategy({client: authConfig.client}, function(tokenSet, userinfo, done) {
return done(null, tokenSet.claims());
});
},
}
*/
function setupAuthentication(app, authConfig, next) {
Issuer.discover(authConfig.issuerURL).then((issuer) => {
authConfig.client = new issuer.Client(authConfig.clientInfo);
app.use(passport.initialize());
app.use(passport.authenticate('session'));
passport.use(authConfig.type, authConfig.createStrategy(authConfig));
passport.serializeUser(function(user,done) {
done(null, user);
});
passport.deserializeUser(function(user,done) {
done(null, user);
});
next(function checkAccess(role, req, res, next) {
function checkRoles(req, res, next) {
if (req.user && req.user.realm_access &&
req.user.realm_access.roles.includes(role)) {
return next();
}
res.sendStatus(401)
}
if ( req.isAuthenticated && req.isAuthenticated()) {
req.session.redirectAfterAuth = undefined;
checkRoles(req, res, next);
} else {
req.session.redirectAfterAuth = req.originalUrl;
passport.authenticate(authConfig.type,
authConfig.passportOptions)(req, res, () => {
checkRoles(req, res, next)});
}
});
});
}
const app = express();
app.use(bodyParser.json());
// Enable CORS support
app.use(cors());
const memoryStore = new session.MemoryStore();
app.use(session({
// ****** See http://expressjs.com/en/resources/middleware/session.html
// for best practice for choosing/managing the secrert
secret: 'some secret',
resave: false,
saveUninitialized: true,
store: memoryStore
}));
setupAuthentication(app, authConfig, (checkAccess) => {
app.get('/service/public', function (req, res) {
res.json({message: 'public'});
});
app.get('/service/secured', checkAccess.bind(null, 'user'), (req, res) => {
res.json({message: 'secured'});
});
app.get('/service/admin', checkAccess.bind(null, 'admin'), (req, res) => {
res.json({message: 'admin'});
});
////////////////////////////////////////////////
// oidic example only
app.get('/logout', (req, res) => {
res.redirect(authConfig.client.endSessionUrl());
});
app.get('/auth/callback', (req, res, next) => {
passport.authenticate(authConfig.type, {
successRedirect: req.session.redirectAfterAuth,
failureRedirect: '/bye',
})(req, res, next);
});
app.get('/auth/logout', (req, res) => {
req.logout();
res.redirect('/bye');
});
app.get('/bye', function (req, res) {
res.send('logged out');
});
////////////////////////////////////////////////
app.use('*', function (req, res) {
res.send('Not found!');
});
app.listen(3000, function () {
console.log('Started at port 3000');
});
}); |
|
IDK if it works or not since I planned to use something less headachy than openid-client for now I just share it to see if it helps someone or not: Here is how I think we can do it in NestJS: https://github.com/kasir-barati/you-say/tree/openid-client |
|
@NickDelta sent you the content of the app. |
|
Thanks a lot ! |
|
@mhdawson Could I also get copy of your app changes? |
|
Sure thing, sent through email. I really should put it somewhere I can link to publicly. |
|
Hi, can I get the copy also, please? |
|
@gkopcak pasted the file in the post above. |
|
After spending quite a bit of time, I found this example for using bearer tokens with rotating keys. I'm still working on the verifying the roles in the token, i.e. replacing |
|
What are your thoughts on express-openid-connect? I found it very easy to use and understand, while I still struggle to wrap my head around openid-client + passport.js. |
|
While I did get |
|
@austincunningham does it work for multi tenant operations or we need to pass realm detail for issuer every time. Could you please explain. |
|
I don't have a use case where I needed multi tenant, but with express-openid-connect you can use the same middleware with different parameters to protect different login routes. The answer at the bottom of this discussion might give you some ideas: auth0/express-openid-connect#161 |
|
@abhinandanbh I haven't tried anything around multi tenant operations. So I don't have an answer for you. |
|
After spent my weekend on the current Node.js adapter i finally found this discussion. PLEASE UPDATE AT LEAST THE README WITH A FUTURE DEPRECATION NOTICE ASAP Sorry to shout, but really ... The cool thing of current nodejs adapter is that yes, it's really fast to implement and easy to understand ... and patch. The bad thing of current nodejs adapter is that you can't use it a docker context if your development domain names are not DNS resolvable or have a complex config (i.e reverse proxy in front of keycloak for SSL/TLS offloading). Regarding alternatives, i'm using https://www.npmjs.com/package/grant (123,289 weekly downloads) for years for authentication but in oauth2 context only. It pretend to play well with keycloak. I have to investigate this deeper. Much more flexible than passport and perhaps a little bit less complicated than openid-client (imho). |
|
I have spent quite some time trying to integrate Node.js adapter with my application. I learned about deprecation only by accident, while reading through some unsolved issues. Please update the documentation and README files. |
|
The README has been updated and the NPM package has been deprecated as well. Installing it will give users a warning. |
|
I have made the same experience as so many others here: keycloak-connect is very straightforward and simple to use. express-openid-connect is not so much straightforward and I am still struggling getting it working with online validation (where keycloak-connect worked out-of-the-box). I then tried the openid-client package. It is more low-level than keycloak-connect and I had to write about 100 lines of code to make it work for my case. That is ok for me and seems the more reasonable solution than express-openid-connect. So a 👍 for openid-client. |
|
Thanks for the feedback, we'll take this into account in our final recommendation. |
|
Hey, I'm new with Keycloak and authentication in general. So this is a stypid question, but what actually is the purpose of this adapter? So considering a fullstack application with frontend and backend: |
|
it would do the stuff you describe on node with express //...
app.use( keycloak.middleware() );
// on endpoints you could then do:
app.get( '/complain', keycloak.protect(), complaintHandler ); |
|
From my point of view, keycloak-connect as so much functionality that I did not find in any of the packages which I have tried to integrate. Some packages have different functionality altogether like @keycloak/keycloak-admin-client But it also does not provide what the most users and developers are looking for in the adapter.
For now, I think the developers are having no way of using keycloak in nodejs and they know the adapter is deprecating so they can't use it and there aren't any good alternatives for it. So they are stuck or writing their own code for integration keycloak with their application. |
|
I didn't find @keycloak/keycloak-admin-client for DAYS. I think this comment was the only place I saw it mentioned for a while and I didn't look into it at first. At this point for me it's doing everything I need and I'm just thrilled that something is working. I'm only planning on having the backend client be used for operations on users (namely creating them). I think it is totally fine for doing that. Maybe it has had more features added by now. All the rest of my code will use next-auth for getting users & roles to authorize certain actions. For anyone out there seeking a solution, I recommend keycloak-admin-client, I just cant believe how difficult it is to find. Also, the example on the repo didn't work for me, I had to add a clientSecret prop to the config and change grantType to 'client_credentials' instead of 'password'. |
|
Thanks everyone for your input, we have decided to delay the removal of adapters, and will come back with more details around Node.js in the future, but for now rest assured they will continue to be supported for quite some time, and we will find suitable alternatives prior to eventually removing the Node.js adapter, including support for Keycloak Authorization Services. For more information around the updated plans please see https://www.keycloak.org/2023/03/adapter-deprecation-update.html. |
|
Will you then please remove the depreciation message in docs and on npm page? Thanks. |
|
We still intend to remove the Node.js adapter, even though there is no official replacement it is still deprecated. As per the definition of deprecated:
|
|
I don't know if this is the right place to put this question to, but I was wondering, in order to only validate Keycloak access tokens without this library, which express-like middleware can I use? |
|
There is no need for a dedicated library, you just need to send an https POST request to You might think checking the token locally is better, but then you won't notice when the session was terminated. |
|
Ok thank you, very useful! |
|
I was considering a library in order to somehow cache the public key and avoid calling keycloak at each resource server call |
|
@bodograumann do you know of any online guides or recipes for interacting with keycloak via REST API (not through SDKs).Im just getting started with this so interested in sequences to go from authentication to authorisation. |
|
No, not specifically, @laurencefass . Mostly it is OIDC / OAuth2. |
Suggestion on related docs improvementI believe docs are missing details in multiple important places. I opened an issue with few suggestions on improvements. |
|
@stianst Thanks for all the work on Keycloak! I saw the note about the Node.js adapter deprecation and just noticed it's been a couple of years since that update. Curious if there have been any developments or recommended alternatives for using Keycloak with Node.js since then? Or maybe any community projects you'd suggest looking into? Would really appreciate any pointers—thanks! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Keycloak is deprecating most adapters in the future, for more information see https://www.keycloak.org/2023/03/adapter-deprecation-update.html.
The Node.js adapter although having a fair amount of usage is not something we are able to continue to maintain due to lack of capacity and developers familiar with Node.js on the team. It has also suffered from lack of maintenance over a longer period of time.
We are actively looking for alternatives to recommend, and would love feedback in this regard.
All reactions