#oidc

🚨 Dropbox Hack / Data Breach: Lenovo ID Flaw Enabled Account Takeover A serious Dropbox security incident highlights a dangerous weakness in federated identity. Attackers allegedly registered Lenovo IDs using victims’ email addresses, then abused Dropbox SSO / OIDC federation** to authenticate against existing Dropbox accounts. The disturbing part: • No Dropbox password was required • Victims didn't necessarily have a Lenovo ID • The attack relied on email-based account matching • A rogue identity could become a trusted federated identity • Attackers could obtain a legitimate-looking Dropbox session This is essentially an account takeover through an identity-provider trust failure, not a traditional password compromise. The full technical breakdown covers the Dropbox hack, Lenovo ID vulnerability, OIDC attack chain, federated authentication flaw, affected users, Dropbox's remediation, and defensive recommendations: https://thecybersecguru.com/news/dropbox-breach-lenovo-id-account-takeover/ #Infosec #CyberSecurity #Dropbox #DropboxHack #DropboxBreach #DataBreach #AccountTakeover #Lenovo #LenovoID #OIDC #SSO #FederatedIdentity #IdentitySecurity #CloudSecurity

@dansup@mastodon.social Full agree: the Fediverse needs to become easier and more familiar to use. But that should mean open, self-hostable standards too. I would really like to see #OIDC / #OpenID Connect as a built-in option — like #Mastodon supports, or #PeerTube can gain through plugins — alongside Sign in with Apple, Google, etc. For Pixelfed, an easy .env-based configuration for a generic OIDC provider would be ideal: issuer URL, client ID, client secret, scopes, redirect URI — done. That would let instance admins use #Keycloak, #Authentik, #Zitadel, their university/work SSO, or any other compatible provider. Does #Loops have plans for generic OIDC login? And is this planned for #Pixelfed as well? Making sign-up familiar matters. Making it interoperable and self-hostable matters just as much. #OpenIDConnect #SelfHosting #Fediverse

I'm considering self-hosting Pocket ID to use as an OIDC identity provider for various other self-hosted services. It's small and simple and easy to understand, but there's a big gap: high availability. If I set up an instance on a machine somewhere, and that machine dies, every service using it as an IdP is temporarily inaccessible until the situation is cured. How do other self-hosters address this situation? I understand at some point there are single points of failure, but I'd like to avoid this being one. #SelfHosting #OIDC #Homelab

Quick update - after evaluating the different options I settled on #kanidm It offers everything that we need, is light-weight, and is mainly managed through the CLI (yes, that's an advantage from my point of view). It comes closest to #FreeIPA in terms of functionality and all that without requiring any additional services or extras. I've already installed a test server and managed to set up #OIDC for all services. Basic authentication is working fine but I still have to test group membership handling, particularly also for new users. Same for SSH login and POSIX user/group features. OIDC for #nextcloud was a bit of a hassle as its internal UIDs were non-standard. I had to manually change them for all users in the database and filesystem. To be continued...

CERT/CC discloses six Logto vulnerabilities, including CVE-2026-15611 and CVE-2026-15616, that enable SSO authentication bypass and MFA skipping. #Logto #SSO #SAML #OIDC #MFABypass #CERTCC https://securityonline.info/logto-vulnerabilities-sso-bypass/?utm_source=mastodon&utm_medium=jetpack_social

CVE-2026-53513 is a Better Auth SSRF flaw (CVSS 9.6) in the SSO plugin. It exposes cloud metadata and enables account takeover. Patch to 1.6.11 now. #BetterAuth #SSRF #CVE202653513 #SSO #OIDC https://securityonline.info/better-auth-ssrf-cve-2026-53513/?utm_source=mastodon&utm_medium=jetpack_social