I'm designing authentication for a company with several microservices and frontend portals. Users should be able to sign in either with Google or with credentials managed by the company, and the portals will call multiple backend services. We don't currently need delegated authorization on behalf of other users.
OIDC seems appealing because it is a standard authentication layer built on OAuth 2.0 and supports federated login. However, I'm struggling to understand how the authorization code flow should work for users signing in through our portals. The browser normally redirects to an internal or external identity provider, while I would prefer to show a login form in our own interface and pass the credentials to the identity provider behind the scenes.
Is OIDC still the right choice for first-party applications, including applications that do not need social login? How do organizations provide a seamless-looking login experience using popups, embedded branding, or customized identity-provider pages? Is a redirect unavoidable, and what is the recommended architecture for handling both Google users and users with company-issued credentials?
5 Answers
OIDC is a sensible choice for first-party applications too, especially when you have multiple portals and services or want to support Google later. You generally want an identity provider that you operate or trust rather than implementing one yourself; products such as Keycloak or Zitadel can handle local accounts and federation. The portals can then establish their own sessions after the OIDC login, while backend services validate access tokens as appropriate.
A redirect is part of the authorization-code flow, even if it is visually hidden. You can open the provider's authorization URL in a popup and have the callback page send the result back to the main window before closing, but the browser still visits the provider and performs the redirect. A normal redirect is usually simpler and more reliable, particularly with third-party cookies and popup blockers.
The application should not collect a user's identity-provider password and forward it behind the scenes. That defeats an important security boundary and prevents the identity provider from choosing other authentication methods, such as passkeys or multifactor authentication. The user should enter credentials only on the identity provider's page or an officially supported provider-hosted component.
Avoid the old implicit flow and password grant for a new system. Use authorization code flow with PKCE, even for first-party clients. Provider branding or a hosted/customizable login page can make the experience look consistent with your application, but poor customization alone is usually a user-interface limitation rather than a reason to weaken the security model. Evaluate another provider if the presentation requirements are important, while keeping the standard browser-based flow.
Keep authentication and application sessions conceptually separate. After a successful OIDC login, the portal can create a secure session cookie for the browser, while services can receive short-lived access tokens intended for those services. An ID token describes the authenticated user to the client and should not be treated as a general-purpose API access token. For local company accounts, the same identity provider can authenticate the user; you do not need a different custom protocol just because federation is optional.
That makes sense. My main concern is the visual disruption, so I was hoping a popup or more heavily branded provider page could make the transition feel seamless without handling passwords ourselves.