Every new product asks for a new password, and every new password is one more thing to forget, reuse, or lose. Delegated sign-in exists to break that pattern: instead of trusting every app with its own credential database, you let an identity provider you already use vouch for you.
The idea: delegate authentication
OAuth 2.0, usually paired with OpenID Connect for sign-in, lets an application ask a provider like Google, Microsoft, or Apple to authenticate the user on its behalf. The flow in brief:
- The app redirects you to the provider.
- You sign in there (or are already signed in) and approve the request.
- The provider sends the app back a token asserting who you are.
The important property is what the app never sees: your password. The provider handles the credential, the second factor, the suspicious-login checks. The app receives a stable identity reference and builds its own profile on top of that.
This changes where the security burden sits. A small team no longer has to store password hashes, build reset flows, and get credential-stuffing defense right. It inherits the provider's investment in account security instead.
The trade-offs
Delegated sign-in is not free:
- You depend on the provider's availability and policies. If Google sign-in has an outage, your users do too.
- Account linking is a design problem. If someone signs up with email, then later clicks "Sign in with Google" using the same address, is that the same account? Getting this wrong creates duplicate identities or, worse, account takeover paths.
- Institutional users bring their own identity systems. Universities and enterprises often already run Microsoft Entra ID. Supporting only one provider means telling those teams to maintain a parallel identity just for your product.
- Authentication is not authorization. Proving who someone is says nothing about what they may access. That part stays in your application, and it is where most real access-control work lives.
How we approached it at Andika
Andika, the knowledge workspace we are building, now supports Google, Microsoft and Apple sign-in alongside email and password. When someone signs in with Google, Google handles authentication and Andika never receives or stores the Google password. We create an application profile in our own database linked to the provider's stable identity reference, and manage workspaces, permissions, invitations and preferences on top of that.
We rolled this out in stages: Google sign-in was configured and working first, while Microsoft Entra registration and Apple Developer enrolment were still in progress. Microsoft support mattered to us specifically because universities and enterprises, the organisations we want to serve, commonly manage identities through Entra ID already.
One boundary we keep explicit: authentication stays separate from connected storage. Signing in with an external identity provider does not hand over your documents or infrastructure. Identity is verified before access is granted, and each organisation keeps control of where its information lives.
Easier to enter, without weakening the parts that keep knowledge safe.
This post is adapted from announcements on the Andika blog. All product sketches are hand-drawn by Andika's founder on a tablet before rendering.
Top comments (0)