Hey everyone,
I've been diving into OpenID Connect (OIDC) and the whole area of authentication and authorization for web apps, particularly as I'm working with Spring's Authorization Server and OAuth2 setup. I'm aiming to enable users to sign up or sign in using social accounts like GitHub or Google, while also managing traditional email and password logins.
The tricky part for me is figuring out how companies handle this dual flow—allowing users to register normally with email and password alongside the OIDC method. Should I keep OpenID clients separate from traditional users in my database? Can OIDC be adapted to manage both types of authentication?
I'd really appreciate any insights or resources that could guide me on implementing this common flow effectively. Thanks!
1 Answer
When using OIDC, you're relying on a third-party identity provider (IdP) for user identities. These IdPs typically provide unique user IDs. If you want to allow users to register with their email and password, you would need to check your database to see if they’re already registered by their email, but keep in mind some IdPs might obscure emails (like Apple’s sign in). That means a user could have two accounts if they use different methods. It's better to have an internal user ID that links to IDs from various providers.
So, yes, store OIDC users in the same database as your regular users. This way, you can streamline account linking in the future. Just use a consistent internal ID as the main identifier.
Exactly! You could start by having a unified flow for registration where users can register with either social media or an email and password. It might complicate things if you maintain two completely separate flows, as you'd have to manage two different user experiences. Linking accounts later can simplify user management.