OIDC - Optimal Practices for Implementing OpenID Connect on the Client Side

In this article, An Optimal Practices for Implementing OpenID Connect on the Client Side

Introduction

In the realm of modern web application development, user authentication and security are of utmost importance. OpenID Connect (OIDC) has emerged as a widely adopted protocol for achieving secure user authentication and identity management. An OIDC client, when integrated with an Identity Provider (IDP), forms a robust foundation for establishing secure access controls and seamless user experiences.

• Understanding OIDC and IDP

  • OpenID Connect is an authentication protocol built upon the foundation of OAuth 2.0. It adds an identity layer to OAuth, enabling applications to verify the identities of users. OIDC introduces concepts such as ID tokens, which carry user identity information, and UserInfo endpoints, which provide user profile details.
  • An Identity Provider (IDP) is a specialized service responsible for authenticating users and providing identity-related information. It acts as a trusted third party that verifies user identities and issues identity tokens, which are then used by applications to grant access.

• The Role of an OIDC Client with an IDP

  • An OIDC client, when integrated with an IDP, facilitates a secure and user-friendly authentication process. It allows applications to delegate user authentication to the IDP while gaining access to necessary user identity information. This integration provides several key advantages:
    • Centralized Identity Management: Applications offload the complexities of user authentication to the IDP, ensuring consistent and standardized authentication processes across multiple services.
    • Single Sign-On (SSO) Experience: Users authenticate once with the IDP and gain access to multiple applications seamlessly, enhancing the user experience and reducing the need for multiple login prompts.
    • Enhanced Security: OIDC clients leverage the IDP's robust authentication mechanisms, including multi-factor authentication (MFA) and adaptive authentication, to bolster security and prevent unauthorized access.
    • Token Management: The OIDC client securely manages tokens, handling tasks such as token expiration, refreshing tokens, and validating token signatures.

• The Role of an OIDC Client with an IDP

  • To implement an OIDC client with an IDP, developers integrate OIDC libraries or SDKs into their applications. These libraries simplify the OIDC flow, token handling, and interaction with the IDP's endpoints. Implementing the client involves configuring endpoints, handling user authentication redirects, obtaining tokens, and using those tokens to access protected resources.
    

Usage

Best Practice 1: Implementing an OIDC client using xbase-config

Good Example:

Using xbase-js

const xbaseConfig = {
  Auth: {},
  API: {},
  Permission: {
    permissionResolver: async () => {
      try {
        const userData = await Auth.getSignedInUser();
        ..... // YOUR CODE HERE //
      } catch (e) {
        window.location.href = "/login";
      }
    },
  },
};

Bad Example:

On mounted of root application

onMounted(() => {
  ..... // YOUR CODE HERE //
})

Best Practice 2: IDP Configuration

Good Example:

Configure the setup with certain mandatory variables that specify the case required by our Xbase service IDP.

authority: // your authority,
client_id: // idp client id,
redirect_uri: you redirect url + "/logincallback",
silent_redirect_uri: your silent redirect url + "/oidccallbacksilent",
post_logout_redirect_uri: // your yourl after log out + "/login",
scope: "openid profile api",
response_type: "code", // makesure that use code flow
fetchRequestCredentials: "omit", // this variable is mandatory for our xbase idp

Bad Example:

The configuration includes a response type with a value other than "code" and not encompass fetchRequestCredentials, or if included, the fetchRequest credential value other than "omit"

authority: // your authority,
client_id: // idp client id,
redirect_uri: you redirect url + "/logincallback",
silent_redirect_uri: your silent redirect url + "/oidccallbacksilent",
post_logout_redirect_uri: // your yourl after log out + "/login",
scope: "openid profile api",
response_type: "token", // not using code flow
fetchRequestCredentials: "same-origin", // same-origin value will carry on cookie

Best Practice 3: Implementing an OIDC client within a route guard

Good Example:

Implement on router guard

router.beforeEach((to, from, next) => {
  const requiresAuth = to.matched.some(record => record.meta.requiresAuth);
  if (requiresAuth) {
      mgr.getRole().then(
        sucess => {
          if (to.meta.role == sucess){
            next();
          }else {
            next('/accessdenied');
          }
        },
        err => {
          console.log(err);
        }
      );
  } else {
    next();
  }
});

Bad Example:

On watch of route changes

watch(
  () => route.path,
  () => {
    ..... // YOUR CODE HERE //
  },
  {
    immediate: true,
  }
);

Best Practice 4: Implementing an OIDC client within a route guard

Good Example:

Removing first the default token expired then state the new call-back

Auth.events.removeAccessTokenExpired(Auth.accessTokenExpiredCallback);
Auth.events.addAccessTokenExpired(async () => {
  await Auth.signOut();
  router.push("/login");
});

Bad Example:

Overwrite without removing the default

Auth.events.addAccessTokenExpired(async () => {
  await Auth.signOut();
  router.push("/login");
});

By following best practices and understanding OIDC specifications, developers can ensure that the OIDC client seamlessly interacts with the chosen IDP, offering a secure, efficient, and user-friendly authentication experience.