This project is back under active development and maintenance!

[thomseddon]

Hello!

After a hiatus following the 3.0.0 release, I'm very happy to say that I will am planning to pick up the maintenance and development of this project. The point of this issue is to outline the plan.

History

3.0.0 was released in August 2017, when the project was already 4 years old, and was the result of a great amount of effort from a number of people in iterating towards a much improved codebase and documentation. Unfortunately, following this all of us who were involved in the release became rather busy with projects elsewhere and were not able to continue to work on the project. As such, we've been stuck on 3.0.0 since then!

I put out a request for maintainers in 2019, although I did receive a few responses I didn't find anyone who was able to start in earnest.
The action that drew most traction was a complete rewrite of the project in typescript in #564 - this was great to see, as was the amount of attention it got which showed there were still a good number of people using or interested in the project.
However, after observation of the progress of that project it's clear that the maintenance is still one of the hardest parts of such a project and I can understand why anyone would struggle to take that on. I realised that another big rewrite really wasn't what the project needed.

A change in my working situation has left me with a little more time to spare, I've been mostly using this on another OS project of mine (https://github.com/thomseddon/traefik-forward-auth) but I'd like to try and pick up this project too.

Plan

In summary:

• v3 - backwards compatible bug fixes only
• v4 - largely backwards compatible fixes and improvements (no code/model changes required)

A lot of people have been lingering on the 3.0.0 release for a long time and has certainly been battle tested. We've amassed over 100 issues and 22 PRs for this release so I would like to make a big effort to give v3 the fixes it deserves. I have already started this by updating all dependencies and releasing 3.0.2 🎉
In honour of the backwards compatibility, I will also be maintaining support for node 4/6/8 in v3.

Due to the nature of the project, most changes do change the server behaviour and so can be considered "backwards incompatible". To help prevent any jarring changes, the plan is for a v4 release which is as backwards compatible as possible. My goal is to keep the integration entirely backwards compatible, so there should be no client code changes required at all for this entire release. We will drop support for EOL node.js version 4/6/8 and plough through as many fixes and improvements as possible.

Thanks for your patience over the years, I'm already enjoying getting stuck back in again!

[Uzlopak]

Will v4 based on v5?

[thomseddon]

No, it will be based on v3 and be mostly backwards compatible with existing code

[Uzlopak]

Is it planned to implement those changes from v4 also in v5 or is v5 now dead?

[mayrbenjamin92]

So are you planning to "throw-away" all of the efforts that went into v5? Isn't Typescript meanwhile the de-facto standard for writing larger JavaScript-based projects?

[thomseddon]

All code has bugs - with v3 we have a somewhat battle hardened release with over 100 issues/PRs raised in this repo outlining many real bugs, doc issues and proposed features.

Whereas v5 is a massive rewrite with significantly less review in comparison - it may address some existing bugs, but will undoubtedly introduce new bugs.

As mentioned above, In the interest of forward momentum I'd like to fix the bugs and make the project better 👍

[jankapunkt]

Thanks a lot for going this path. It's great to see, that I can continue to rely on this package. Is there a way to send a small donation 💰 to show some ❤️

[desaijay315]

We are with you. Thank you so much for the support and the awesome work you are doing?

[Rmannn]

Is v5-dev branch really dead ? As i understand, typescript version is not any more in the roadmap.

It's true, it's important to be backward compatible, but it's also important to move forward and update the code to support latest features of oauth2.

Some of thoses features were implemented in v5-dev and we were waiting for those to be merged. Better typing,
Pkce was also one of them. Can we expect to get it soon ?

You talk about v4, but we didn't see any branch related to it. Is this really planned ?

We know it's important to get help.
How can we help you to move forward ?
We just won't want to write code that is going to be "throw-away" like in v5-dev.

[jankapunkt]

I think it would be great to have a v4 branch and a v4 project that contains all the issues relevant for v4. By doing so we know where to put our efforts in.

@thomseddon what do you think?

[thomseddon]

👍 3.1 will be released next week (3.1.0-rc1 is published on npm now)

The existing next branch was actually pegged for v4 and includes some necessary breaking changes. I'll create a new v4 branch shortly which will be based on the existing next branch, rebased from master/v3-catchup (#629)

I'm hoping to merge the existing PKCE PR into v4 too.

For those that have asked about sponsorship - thank you so much, I'd really like to spend more time on this project (there's a lot of work to do :) and I've setup github sponsorship, so for anyone who would like to help in that way it would really allow me to focus more time into this and would be greatly appreciated.

[gabriprat]

Hi! Any news on PKCE implementation?

[Uzlopak]

This Project is imho again dead.

[jankapunkt]

I think there should be someone getting sponsored to tackle the remaining issued or at least to manage incoming PRs.

[night]

@thomseddon honestly i'd say put v3 into maintenance mode (security fixes only), skip v4, and start pushing forward on v5 /w typescript and breaking changes. it's daunting work to build out improvements for 3 separate versions. if you don't have much time then reducing the surface area will surely help, and the typescript branch seems much cleaner to work with and build upon.

[ukneeq]

Is there a branch already for v4?

[jankapunkt]

I agree with @night that managing 3 versions is a huge effort and maybe also the reason this repo getting stuck again?

@ukneeq I think it's the dev branch

[Uzlopak]

I dont think, that the complexity is the reason that this project got stuck again. I suppose when @thomseddon was claiming that this project is under active development and maintenance, that he was in a jobless situation and thats why it was back under development... But soon after he was again busy with a job which supplies him with money. And so this Project is stuck again. I mean it is totally understandable, I would also be less productive in an open source project, if I have a paid Job.

What you gonna do? Issue is also, that this is a security relevant product. If you have a not trustworthy contributor/maintainer which puts malicious code into the product, then alot of companies will be hackable. But on the other hand, we can have a critical community and make it necessary to have x approvals before the maintainers can actually merge into master. I would also agree that new maintainers need to disclose their identities and who their employers are, so that making them to be maintainers does not mean to make a malicious anonymous able to taint the code.

I would be happy if I could support this Project.

[jankapunkt]

I Support the Idea

[HappyZombies]

If you are still in need of maintainers let me know, I really enjoy using this module and would be happy to contribute and improve it as much as I can!

[Uzlopak]

Maybe we should Talk with another group Like auth0 and ask if they fork it and maintain it with our community support.

[HappyZombies]

>This project is back under active development and maintenance!

Sooo that was a lie.

[jankapunkt]

Would be great to have at least some kind of election for maintainers so this can continue to stay alive.

[jorenvandeweyer]

I think there would be a lot of people willing to maintain this project. The only thing that is missing are specifics tasks or todos that people can assign to themselves.

Personally I think the typescript version (v5) should be picked up again.

[jankapunkt]

If we could define some reliable criteria for someone becoming a trusted maintainer we could start elections and @thomseddon only needs to add them. I think from there we could work in fixes for 3.x and 5.0 as well

The trusted maintainers can assign taks, review and merge PRs

[svrnwnsch]

I think the minimal effort should be to at least merge in updated dependencies e.g.: #677 and similar

[Uzlopak]

I wrote this today to auth0:

Hello Auth0 Dev Team,

I wanted to ask you if your developers could fork the node-oauth2-server project on github.

https://github.com/oauthjs/node-oauth2-server

Alot of products use this project but the maintainer of the project abandoned it. We, the community, provided various PRs for this product, but till today the maintainer does not merge anything. We discussed about forking off the project, but tbh. this product is too security sensitive to have it maintained by the community in a noname github repo.

I personally would prefer if auth0 would be the trustworthy maintainer of the product. So you would fork the project and continue it as e.g. auth0/node-oauth2-server. We, the community, could then provide PRs and could have atleast some progress.

I hope you join us in the discussion on github:

#621

Thank you very much!!!

Best Regards
Aras Abbasi

[Uzlopak]

I wrote an identical E-Mail to the CEO of auth0.

Lets hope this project gets finally the love it needs. :)

[mjsalinger]

Published 4.0.0-dev.3 which mainly contains dependency bumps under the dev tag on npm. Now that I have this going, expect a regular cadence of dev releases over the next several weeks - let me know if you encounter any issues. I'll continue to announce dev releases here for the time being, with the hopes of a beta by end of June/early July. Let me know what you'd like to see in this release and I'll try to get those in. PKCE seems to be a big one that I'll shoot to review next.

Changelog

• Bump jshint from 2.12.0 to 2.13.0
• Bump jshint from 2.12.0 to 2.13.0
• Upgrade to GitHub-native Dependabot
• [Security] Bump lodash from 4.17.19 to 4.17.21

[Milad]

@mjsalinger what about those who are using v3? It would be really helpful to bump dependencies for that generation. lodash is also vulnerable there!

[dhensby]

The 3.x branch will be preserved (and brought up to date) but also deprecated, no furhter changes will be made to this branch. master (will be renamed to main) will get the 3.x latest changes as that is the last stable release for now.

[HappyZombies]

@mjsalinger how are things going? Need assistance with anything? Currently using 4.0.0-dev.3 and it's working good so far! Appreciate the dependency updates 👏

[jankapunkt]

Can confirm the same with our authorization code workflow and 4.0.0-dev.3 - everything runs fine, no issues since we installed it.

[mjsalinger]

Update: Currently reviewing and testing the PKCE code - want to put that through its paces a bit, should have it merged and a dev release tagged early-mid next week sometime, possibly along with a few other smaller PRs...

[jwerre]

Would it be possible to remove the following dependencies?

• bluebird -> Native Node Promise
• promisify-any -> utilis.promisify
• statuses -> http.STATUS_CODES

[dhensby]

@jwerre - I think you should probably open issue(s) for those things and even consider authoring the PR.

[Uzlopak]

Actually Changes sound interesting. Maybe the Bluebird replacement should be done in the way that we kind of dependency inject it. Fallback is native Promise implementation. If there is somebody for any reason depending on bluebird or thinks it is faster, he can just override it with Bluebird?

[jwerre]

@Uzlopak mongoose does something like that, not a bad idea. I'm not sure why you'd need to do that though, Promises have been available since version 0.12.0. There's really no need to shim Promise anymore.

[Uzlopak]

Exactly. I thought about mongoose. back in those days performance of native promises was slower than bluebird. But tbh we are now at node 14/16. The performance bottleneck does not exist anymore.

I just think we should consider this.

I personally prefer to use native Promises, without the injection technique I mentioned.

[jwerre]

@mjsalinger I'd be happy and go through the code and make these changes. That said, I understand the security implications.

[Uzlopak]

Please make them separate. One for promise, one for utils.promisify and one for the statuses. I would review then

[jwerre]

Status update?

[HappyZombies]

We just need one new, serious maintainers; there's clearly there's no communication or time from the current maintainers, and I also feel like there's no time to "build a level of trust" when the maintainers themselves aren't even active here.

[HappyZombies]

Everyone, I went ahead and just forked on this project and will work on it, hop on hover and let's talk about the future of the project over there.

The project is now under a new organization for easier development.

https://github.com/node-oauth/node-oauth2-server

[jankapunkt]

I will join, however I still would love to see this project getting things done or finally making people maintainers that actually have the time and commitment to improve things. I think there were numerous mentions in this thread who would participate etc.

[jankapunkt]

cc @Uzlopak @jwerre @dhensby @Milad @jorenvandeweyer @ukneeq @night @gabriprat @mayrbenjamin92 @desaijay315 @Rmannn please also think about what you would invest to keep this alive, maybe under a new organization, we would be enough people to cover most aspects of the development process for maintenance and maybe even continue to improve.

We can use the fork of @HappyZombies in the meantime to discuss things further and don't further pollute this thread

[HappyZombies]

@jankapunkt good idea about making this an organization and just adding people, I'll carry the conversation over there.

[jankapunkt]

I see many of you reacting confused and I'd like to know why. I know it's hard to just jump from a 3.4k stars project with established level of trust to something empty but I for example can't wait for all the vulnerabilities to be closed in 2022 because we have an audit soon. I don't know your situation but I prefer to keep such a critical tool updated as possible.

[thomseddon]

Hey - from my side, I'm actually happy to see the fork! As mentioned before, I've always had a security concern with promoting a maintainer without at least establishing a base line level of trust and competence. I've suggested to those who are willing to begin triaging but I can certainly see how a clean fork is easier.
If the fork goes in the right direction I'm happy to provide maintainer access for it to be merged in or replaced as is seen fit.

[mayrbenjamin92]

Can anybody suggest a good and "non vulnerable" fork? I am happy to start dedicating some of my spare time to support this project - we are heavily relying on it and having the vulnerabilities is a mess :/

[jorenvandeweyer]

Can anybody suggest a good and "non vulnerable" fork? I am happy to start dedicating some of my spare time to support this project - we are heavily relying on it and having the vulnerabilities is a mess :/

@mayrbenjamin92

This is an active fork with the issues fixed.

https://github.com/node-oauth/node-oauth2-server