It's probably worth adding those PRs:

• Merge develop in to openidc #3952
• FEAT: Open ID Cconnect authentication #2630

Seems like there are multiple PRs implementing the same feature, it's probably the best to wait for@jc21 to decide which one to merge.

@CrazyWolf13 This is a continuation of the abandoned#2630 PR and#3952 was done as part of this PR it looks like. We just need@jc21 to take a look and merge if everything is good

Any update on this? I would love to see it merged

There are conflicts, and CI won't build you a docker image until they're resolved

There are conflicts, and CI won't build you a docker image until they're resolved

Thanks for clarifying, I will resolve them later today.

I'm glad this PR will be finally merged! Thanks a lot for the effort of all the people involved@jc21@oechsler@Shocktrooper

Yes many thanks for the contribution but don't count your chickens just yet. This is a big PR and it will need thorough testing both with OIDC and without. I'd feel happier if there was some cypress tests for both scenarios as well.

Besides Authentik, can we get this tested with other providers too?

Also some documentation will need to be added around this

Yes many thanks for the contribution but don't count your chickens just yet. This is a big PR and it will need thorough testing both with OIDC and without. I'd feel happier if there was some cypress tests for both scenarios as well.

Besides Authentik, can we get this tested with other providers too?

Also some documentation will need to be added around this

@jc21 - Thank you very much for the review and your feedback on this topic!

Could you possibly elaborate a bit more on what the tests should specifically cover? I don’t have much experience with the Cypress framework, but I’m more than willing to invest the time needed to bring this PR to completion.

As for testing with other OIDC providers, I’d leave that to others in this thread for now, as I currently only have Authentik running. However, with the new Docker test image, it should be straightforward to set up an instance.

I’m also happy to take on the documentation. Given that OIDC isn’t always the most straightforward topic, I agree it would be beneficial to provide clear guidance. Should we add a dedicated section to the documentation for this, or integrate it into an existing section?

- Nonetheless I would also be happy if somebody else could lend a hand 😉

that may be so. and as i said, it's probably fine. But if you would define multiple users in Authelia with same email but different username (e.g. Sven and SvenAdmin) which is absolutely possible, then you'd have a conflict on login. You'd probably just end up in the same Account in NPM.. Which.. considering you have control over the same email address may or may not be an issue.

I made some changes to@oechsler 's branch to address some of the requested items (PRhere).

• Cypress automated tests for updating the OIDC config
• Documentation for setting up SSO with OIDC

I also made the following UI/UX changes:

• A more user-friendly error message for when a user does not exist in NPM and they are attempting to sign in via an IdP
• Fixing a typo in the "hint" description so that the name of "Redirect URL" matches the field label in the modal.

Hey@chutch1122, and thank you also,@svenwanzenried, for testing with other providers, dedicating your time to implementing the Cypress tests, and writing the documentation. I’ll take a look at the changes over the next few days and merge them into the PR branch as soon as possible. I’m really happy to see the momentum behind this feature —great work!

I also added some additional UI-based end to end tests. These tests update the OIDC config to be enabled/disabled and ensure that users can still log in.

I'd like to add some additional tests around logging in with a "dummy" OIDC provider, but this should provide some good coverage and peace of mind that users won't get locked out.

Edit: Not sure why the build is failing. The tests ran on my machine.
Edit 2: Figured it out. Some things changed with error messages since this branch was created. Merging indevelop and updating some of the test expectations seems to do the trick.

Docker Image for build 4 is available on
DockerHub
asnginxproxymanager/nginx-proxy-manager-dev:pr-4010

Note: ensure you backup your NPM instance before testing this image! Especially if there are database changes
Note: this is a different docker image namespace than the official image

@jc21 Do you want E2E tests with an actual mock OIDC provider to be included before merging this in? Other than that, is there anything else you'd like added?

Otherwise, I think it's ready for review again and includes your requests from above.

I've recently added OIDC support to thev3 branch, and that also adds a locally running Authentik server pre-configured.

I'd suggest waiting for me to merge one of the outstanding postgres PR's which I can then add the authentic db to that, then the cypress e2e tests can be improved from there. Here's thev3 test I've written.

Thedevelop branch now has postgres support and Authentik setup in both CI and dev.

To bring up the dev environment:

./scripts/start-dev# and remove it after you're done./scripts/destroy-dev

Then access the web hosts with:

• NPM:http://127.0.0.1:3081
• Authentik:http://127.0.0.1:9000

Authentik notes:

• log in withakadmin:admin
• Support for LDAP and Oauth/OpenID is ready to go
• Login with Oauth/OpenID usingcypress:fqXBfUYqHvYqiwBHWW7f

See the following cypress tests, they are skipped currently however

• OAuth
• LDAP

to run cypress locally:

cd testsyarn installyarn cypress:headless --spec cypress/e2e/api/Ldap.cy.js

@jc21 Any updates?

Would be nice to see this merged. Hope you manage to complete testing this asap

Looking forward to seeing this in the primary docker soon.

Just wondering if any progress has been made with this? I have Authentik setup myself and would be happy to test if additional testing is necessary.

Would love to see this merged, looking forward to working with my keycloak instance without needing some kind of auth proxy middleware

Sorry to add another useless message, but please, when you see that the last 4 messages are nothing but people being impatient about the feature, maybe you could just think twice before posting the 5th message about being impatient about this feature.

Could somebody explained me why this PR can’t be merged from September 2024? Is any unresolved issues? Or are we waiting NPMv3? Please, let us know!

Could somebody explained me why this PR can’t be merged from September 2024? Is any unresolved issues? Or we’re waiting NPMv3? Please, let us know!

As far as I can see in the comments here, this is running in Dev Branch. The developer wants to ensure high quality before unleashing upon the general population. There are some major changes coming.