add a generic oauth/oidc provider

[maltegrosse]

First of all , Great project, thank you!

is it possible to add a generic oauth/oidc provider for self hosted instances, as I already got my private keycloak instance in place. I know in golang a generic library exist, eg used in headscale https://github.com/juanfont/headscale/blob/06f07053eb3ef08c3236483891a94c0b81eb8393/hscontrol/oidc.go#L156 Based on golang.org/x/oauth2

PS a sdk in golang would be nice too;)

[ucarion]

Could you rephrase what you mean by an OAuth/OIDC provider? If what you mean is a way to use SSOReady to make SAML connections look like OAuth/OIDC servers, then I believe you may be looking for what we call SAML-over-OAuth. But if that's not what you mean, I'm all ears.

Golang SDK is in the works! Just need to wire up the codegen for it.

[maltegrosse]

I am sorry for the misunderstanding. https://ssoready.com/docs/self-hosting/self-hosting-sso-ready#supporting-login-methods mention 3 different login methods. Is it possible to add other oauth login methods?

[ucarion]

Thanks for getting back to me and clarifying. I understand what you mean.

The short answer here is: let me think about this.

Just to give you a sense of where my mind is at on this one, my thoughts with adding a custom OAuth login source sort of float around this:

1. How would we document this? Bearing in mind that most folks have difficulty keeping SAML alone straight, and many users rely on SAML-over-OAuth, it's confusing and mentally taxing even to have to evaluate whether any additional settings with "OAuth" in the name is relevant to them.
2. Adding to the confusion and just general subtlety of this ask, the ability to add a custom OAuth login method for app isn't something that would be used for the hosted instance at app.ssoready.com. It just doesn't make sense outside of a single organization's self-hosted instance. That would mean, among other things, that such a feature wouldn't be dogfood-able.
3. This feels like the sort of feature that could lead customers to accidentally pwning or really confusing themselves if they try to use it but don't configure OAuth properly or set up a trust relationship with an OAuth provider they shouldn't trust.
4. My experience is that as inconsistent as SAML can be at times, OAuth is comparably inconsistent as well. It's difficult in practice to just paper over all OAuth providers are being the same thing. I fear this will become a fountain of additional settings and sub-settings to accommodate various quirky OAuth servers.
5. (This is the most important point.) We're planning on adding support for logging into SSOReady using SAML, including for self-hosted deployments. The challenge here, and you could call it a bit ironic, is that many SSOReady users need to implement SAML but do not themselves work at an organization that uses (or wants to use) SAML.

That said, my current inclination is to say that the last point using SSOReady to log into SSOReady itself -- is likely something we'll be doing no matter what. And it sounds like something that in your case would work too, right? I assume you're using Keycloak to do some identity federation stuff (that's the typical way it gets used, in any case) -- you could tell Keycloak to do a SAML-based, rather than OAuth-based, integration with your self-hosted instance of SSOReady?

Sorry for the wall of text here. Just wanted to be open about the thought process that's going on for me here.

[maltegrosse]

@ucarion Thank you alot for your detailed explanation. The last paragraph helps me alot and answered my question - thank you again. I just thought using oauth wouldnt be too much efforts as the current Microsoft/Google using it anyway, so replacing them by a generic oauth provider should work without too many changes

[batmilkyway]

I don't want to speak for @maltegrosse, but for myself I think supporting OIDC SSO connections from IdPs like MS Entra, Okta, Google, etc is a requirement for building a SaaS. Alternatively, if you don't want to support it how about adding an API for managing users?