-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Contribution of an OpenId Connect authentication method #367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
None here is interested in using Google or Github accounts to login to Kutt? |
Thanks for the suggestion, but I'm not interested. |
@dlecan We've been planning on integrating our Kutt instance with our corporate SSO. I'm surprised that OpenID support in Kutt was rejected outright since SSO integrations should be a part of software product roadmaps. Maybe this doesn't fit with the business strategy of Kutt's sponsors, but I'm definitely interested. I'll be checking out kover.link. Do you have other plans for the fork? |
I just found it funny, the sponsor for Kutt is simply @poeti8 himself. The Devs is an international open source group, and we have no external funding at all at the moment. |
For the time being, we are making the minimum investment in our fork, knowing that it also incorporates some of our specific needs. |
@dlecan I understand, that's why it's disappointing there wasn't any interest in a PR for OIDC integration. |
Would you like to make a proposal for integration and maintenance of OIDC support? I'll reopen the issue until then. |
I quote myself (too long posts aren't read 😉):
For this part:
I don't know how we could do that. But as we are already users of Kutt with our https://kover.link service, we will defacto need to make it work :-) But, there are also opened questions, that we've to answer (see |
Before accepting a PR and having you spend time on it, we'd like to see a proposal of how you plan to implement. I don't believe Pouria or I have worked with OIDC in the past, so would need to know the impact on codebase. For example, I'd like to know if/how public API could change, and if it would be breaking. If after adding support, Unikname no longer has a need to maintain Kutt, we would need to maintain it afterwards anyway.
I don't think we can take a feature incomplete version to production, since other Kutt users may have an issue with things partially working, but that can possibly be sorted out by working in a separate release channel/branch until it has feature parity with main release. Thanks for your interest, let's see if we can pool our efforts. |
My use-case is integrating with my company's SSO (AzureAD or SAML). Passport has strategies for everything - including local user account. I think we have figure out how to support passport's other strategies easily in Kutt. |
Not using Kutt anymore, so nothing to contribute |
It would be a nice improvement to integrate support for OIDC and OAuth2. I am sorry the merge was not accepted. |
That should be doable using integrated passport lib, but that would require someone to heavily work on UI and adapt the config to make it usable wildly. |
@dlecan Appreciate your work on OIDC. I cherry-picked your work, cleaned up a bit and continued the development here: https://github.com/rophy/kutt |
@rophy or anyone, possible to bring OIDC or OAuth2.0 to the new kuttit v3.x release? |
@rophy sure, it's appreciated. |
A weekend project at #880, hope it helps. |
Amazing. Looking forward to testing it when the docker arm images release. |
https://github.com/rophy/kutt/pkgs/container/kutt/395424116?tag=sha-4a7f478 |
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I'm the Unikname Connect solution CTO.
🎆 I would like to present Kover, a fork of Kutt where authentication is done with an external identity provider through OpenId Connect (OIDC) protocol.
This allows to use Facebook, Google, Twitter, Github ... accounts to login to Kutt.
The provider is Unikname Connect for Kover.
We are using Kover to hide complex and long URL and to make statistics about them. But without any email and full confidentiality, as provided by the Unikname Connect solution.
👉 https://kover.link
The Github repo: https://github.com/unik-name/kover.link
What has been done?
Basically, we have unplugged the email/password auth method and plugged the OIDC protocol instead, thanks to Passport.js library.
Then, we have configured OIDC to use Unikname Connect OIDC identity provider. But any other OIDC-compliant identity provider would work, such as Facebook, Google, Twitter, Github ...
We have disabled account deletion as it depends on the password.
We also removed the password update feature, obviously 😁
What is missing?
Future
We would like to contribute to Kutt with a generic implementation of OIDC, which would allow using Facebook, Google accounts ... or any other OIDC compliant identity providers.
Are you interested in?
Thank you for your work on Kutt 💪
The text was updated successfully, but these errors were encountered: