OAuth 2.0 and OpenID Connect often appear together on a login screen, so it is easy to treat them as two names for the same thing. They solve related but different problems. OAuth provides a way for a client to receive limited authorization to use a resource. OpenID Connect, usually shortened to OIDC, adds an identity layer so a client can know who signed in. Understanding the boundary helps a business application avoid subtle security mistakes.
What OAuth grants
Imagine a scheduling application that wants to add an event to a customer's calendar. The application can redirect the customer to the calendar provider and request permission to create events. After consent, it receives an access token with a particular scope and lifetime. The token is for an API operation; it is not, by itself, a reliable statement of the person's identity. The resource server checks that token when the scheduling application calls the calendar API. The authorization server decides what the client may access, and the client should request only the scopes it needs.
What OIDC adds
A business application also needs to recognize a person returning to its own site. OIDC uses the OAuth framework but introduces an ID token and a standard user information flow. The ID token contains claims about the authenticated subject and the issuer that authenticated them. The client validates its signature, issuer, audience, expiration, and nonce when applicable. Once validated, the application can associate the subject identifier with its local account. An access token and an ID token have different audiences and purposes; sending the ID token to an API as an authorization credential confuses those roles.
A practical sign-in flow
A browser begins at the application's sign-in page and is redirected to an identity provider. The provider authenticates the user and returns an authorization code to a registered redirect URI. The application exchanges that code for tokens through a back channel. Public clients use PKCE so an intercepted code alone is insufficient to obtain tokens. The application validates the ID token, creates its own session, and uses an access token only for APIs that accept it. A predictable redirect URI and state value protect the return trip. These steps should be handled by a maintained library rather than improvised URL parsing.
Authorization still belongs in the application
Identity does not answer whether a user may edit an invoice, view a tenant's dashboard, or invite a colleague. An authenticated subject can still be unauthorized for a particular action. The application must map the subject to its own tenant, roles, and resource permissions and check them on every relevant request. A claim from an identity provider may help establish a role if there is an explicit trust agreement, but it should not silently replace the application's business rules. The difference is especially important in multi-tenant software, where a valid session for one tenant must not grant access to another tenant's data.
Choosing an implementation
Use OAuth when a client needs delegated access to a protected API. Use OIDC when the client needs a standardized sign-in result. Many products need both: OIDC for the user's identity and OAuth access tokens for API access. Decide which component owns the browser session, where tokens are stored, and how refresh, logout, and account recovery work before wiring up the interface. For an SMB product, a trusted identity provider can reduce the amount of sensitive authentication code the team maintains, but it does not remove responsibility for secure sessions and application authorization.
Common mistakes to avoid
Do not infer the user from an arbitrary access token or decode a JWT without validating its signature and claims. Do not use an email address as the only permanent account key; addresses can change, while the provider's issuer and subject pair identifies an account more reliably. Avoid broad scopes that the application never uses. Keep tokens out of logs and analytics. Review redirect URI configuration and callback behavior in each environment. These checks are simpler than diagnosing an account mix-up after launch, and they provide a clear division of responsibility between identity, delegated access, and business permissions.