OAuth SSO (client)

[nismoau]

Feature Description

Just spotted this project, looks awesome!

The only thing it's missing compared to my current solution is OAuth SSO to third party providers e.g. GitHub, G-suite, MS entraId etc.

Would be awesome if it could be included. I find my current solution works really seamlessly due to GitHub SSO and no need to maintain local accounts.

[azukaar]

I'll keep the ticket open for conversation but at the moment my opinion is this feature is not being considerated, as

• Cosmos IS already a SSO, so the chaining would be weird
• This would undercut some of the features, such as the force 2FA for users, send emails, and so on
• A completely seamless integration is impossible: you would need to invite people to your server on specific providers for them to be able to login, otherwise its' a huge security issue if any google account can login to your server. This in turn might give a not-so-good experience when using multiple provider (ex. Google + Github) if user for example tries to login with the wrong one

[nismoau]

Hey, thanks for the reply and keep up the awesome work!

Fair points. One thing I have noticed however is that exposing a credentials form to the web will result in brute force attacks (mitigated in this case by 2FA) however offloading that to an external OAuth provider does remove the brute force attempts altogether.

[azukaar]

Fair points. One thing I have noticed however is that exposing a credentials form to the web will result in brute force attacks (mitigated in this case by 2FA) however offloading that to an external OAuth provider does remove the brute force attempts altogether.

You can't Brute Force the Cosmos login page, every attempt take 2-3 sec (regardless of servers, it's a literally a hardcoded waiting time) and passwords are forced to 8 characters with symbols, maj and numbers. This means it would take centuries to brute force any password. Also the shield will recognize the brute force attack and block any IP with abnormally high amount of 400 errors (like a wrong login).

That does not mean it's completely safe, it's just mean that any dangers will not come from Brute Forcing

[ankycooper]

Firstly really like the look and feel, keep up the good work!

I am not sure what proxy is being used under the hood, i used to use Traefik with forward auth. Can this be implemented?

Another approach would be running a sidecar with authentik (supports all protocols) just like running mongodb rather than re-inventing the wheel.

External IDP may not make sense for some users but it does for advanced use cases. Federated identities Passkeys/passwordless Phishing-resistant MFA (fido2 compliant) multi-protocol (oidc/oauth2, SAML2, LDAP, radius) for other workloads such as VM, AP, infra stuff, external apps etc

[azukaar]

• it does not have a reverse proxy under the hood, it's Cosmos the reverse proxy
• I agree that external IDP makes sense for /some/ users, but it's a very small minority when talking about home servers. For me, external IDP makes more sense in a business context. In this case this will be delegated to further business related use-cases further down the roadmap

[mandopatriot]

• it does not have a reverse proxy under the hood, it's Cosmos the reverse proxy

  • I agree that external IDP makes sense for /some/ users, but it's a very small minority when talking about home servers. For me, external IDP makes more sense in a business context. In this case this will be delegated to further business related use-cases further down the roadmap

I think an external IdP makes sense because Cosmos currently doesn't support all the same features, at least from my basic understanding. Things like additional redirect URIs, modify and set scopes, ability to stay logged in, store the permissions used for application, groups/user access, etc. Many of my local apps don't support OpenID, so Cosmos simple auth page is enough. But other apps can use OpenID and having more features would make it a lot easier to keep Cosmos as the primary IdP.

[azukaar]

@mandopatriot additional redirect URIs are supported (it's a comma separated list) Not sure what you mean with the other stuff, do you mean altering the scope the app request? is that even legal under OpenID protocol? Cosmos also has user/group access (with user vs. admin group) which translates the same way into OpenID (ex. admins in NextCloud)

i think it makes more sense to improve the OpenID server in Cosmos rather than trashing it out just becaues it is missing 1 or 2 edge-case features

[mandopatriot]

How is having a single auth setup for the majority of uses an edge case feature? That's the goal for most organizations, because if you control the primary auth method then it's easier to secure/manage and is much more simple for users.

My preference would be to improve OpenID in Cosmos as you stated, but if there are more features then there is not enough information about them. Nothing in the Cosmos OpenID guide notes that redirect URI's is a comma separated list nor that you can use user/admin as groups, nor how to create new admin users within Cosmos. I appreciate everything you do, just trying to make suggestions on problem points.