Authentication and Authorization Standards

OAuth 2.0 and OpenID Connect (OIDC) are the standards behind "Login with Google," "Login with GitHub," and enterprise Single Sign-On (SSO). OAuth 2.0 handles authorization (what you can access), and OIDC adds an authentication layer (who you are). At Nexis Limited, our SaaS products support OIDC-based SSO for enterprise customers, and our own services use OAuth 2.0 for API-to-API authorization.

OAuth 2.0 Core Concepts

Roles

  • Resource Owner: The user who grants access to their data.
  • Client: The application requesting access (your app).
  • Authorization Server: Issues access tokens after authenticating the user (Google, Auth0, Keycloak).
  • Resource Server: Hosts the protected data and accepts access tokens (your API).

Token Types

  • Access Token: Short-lived token (15-60 minutes) that grants access to specific resources.
  • Refresh Token: Long-lived token used to obtain new access tokens without re-authenticating the user.
  • ID Token (OIDC): JWT containing user identity claims — name, email, profile picture.

Authorization Flows

Authorization Code Flow (with PKCE)

The recommended flow for web and mobile applications. The user is redirected to the authorization server, authenticates, and is redirected back to your application with an authorization code. Your server exchanges the code for tokens. PKCE (Proof Key for Code Exchange) protects against code interception attacks and is now recommended for all OAuth clients.

Client Credentials Flow

For server-to-server communication where no user is involved. The client authenticates directly with the authorization server using its client ID and secret. Use this for microservice-to-microservice communication and automated processes.

OpenID Connect

OIDC extends OAuth 2.0 with a standardized authentication layer. It adds the ID Token (a JWT with user identity claims), a UserInfo endpoint for retrieving user profile data, and a standardized discovery mechanism (.well-known/openid-configuration). OIDC enables SSO — users authenticate once with the identity provider and gain access to multiple applications.

Enterprise SSO Implementation

Enterprise customers expect SSO integration with their identity provider (Okta, Azure AD, Google Workspace). Supporting OIDC-based SSO involves:

  • Allowing tenants to configure their OIDC provider (issuer URL, client ID, client secret).
  • Redirecting users to their configured identity provider for authentication.
  • Mapping OIDC claims (email, groups) to your application's user model and permissions.
  • Handling just-in-time user provisioning — creating user accounts on first SSO login.

Security Considerations

  • Always use PKCE — it prevents authorization code interception attacks.
  • Validate ID Tokens — verify the signature, issuer, audience, and expiration.
  • Use state parameters to prevent CSRF attacks during the authorization flow.
  • Store tokens securely — use HttpOnly cookies for web apps, secure storage for mobile apps.
  • Implement token revocation for logout and security incidents.

Practical Recommendations

  • Use a managed identity provider (Auth0, Clerk, Keycloak) rather than building your own OAuth server.
  • Support multiple social login providers (Google, GitHub, Microsoft) for consumer applications.
  • Implement OIDC-based SSO for enterprise customers — it is often a procurement requirement.
  • Use short-lived access tokens (15 minutes) with refresh tokens for session continuation.

Conclusion

OAuth 2.0 and OpenID Connect are essential standards for modern authentication and authorization. Use established libraries and identity providers — the security implications of getting authentication wrong are severe. Invest in proper implementation once, and your application has a solid foundation for user authentication and enterprise SSO.

Implementing authentication? Our team has implemented OAuth 2.0 and OIDC across multiple SaaS products.