Identity as a Microservice



Microservices allow applications to be created using a collection of loosely coupled services. The services are fine-grained and lightweight. This improves modularity and enables flexibility during the development phase of the application, making the application easier to understand. When designing applications, identity becomes a key factor to building out a personalized user experience. Identity also enables other microservices for tasks like authorization applications like Axiomatics, single sign-on, identity management and compliance.

However, access to profile data presents a challenge since it is contained across multiple repositories, contained in other applications or even must be consumed from other microservices. The Identity Microservice must be able to not only respond to requests through a standard protocol for identity information, but must also have the means to reach out to these identity repositories in an efficient and responsive manner. The Identity Microservice must also allow for both user-driven and server-to-server access to identity data.

The following diagram breaks down the components of the Identity Microservice:

The Identity Microservice at its core is made up of four layers:

  1. oAuth Authorization Server
  2. OpenID Connect UserInfo Endpoint
  3. Federated Identity Service from applications like Radiant Logic’s FID
  4. The server and web application clients of the Identity Microservice

Each of these layers performs a crucial role in securing access to identity data and also allows the microservice to obtain identity data from the required repositories. Breaking this down further:

  • The oAuth Authorization Server provides secure access to the Identity Microservices
  • The UserInfo Endpoint handles the requests for identity data and returns the requested profile information (claims)
  • The Federated Identity Service provides a centralized hub for obtaining application-specific profile data from directories, applications, databases and other microservices
  • Additionally, the Federated Identity Service needs to be able to aggregate and correlate profile data and leverage a real-time cache to ensure that access to profile data performs quickly and within the required application service levels

Today, the Identity Microservice’s components are based upon open standards and are both lightweight and highly leveraged by web applications and servers.

There are two main client flows supported by the microservice:

  1. User-driven Web Application flow
  2. Server-driven flow

Each of these flows require a different means of interacting with the Identity Microservice.

User-Driven Web Application Flow

Identity is at the core of nearly all web applications - everything from the initial authentication and authorization through to personalization with profile data. When logging into your banking application you not only need to securely identify you as the user, but also must authorize access to your accounts and personalize the site for your profile. Would you trust a banking application that listed your identity as “User”?

The following diagram breaks down the user-driven Web Application flow:

  1. User accesses the Web Application
  2. The Web Application redirects user to the Identity Microservice’s Authorization Server with a client ID and application scope
  3. User authenticates and authorizes request
  4. Authorization Server redirects user back to the Web Application with an authorization code
  5. The Web Application sends the authorization code to the Authorization Server with its client secret
  6. The Authorization Server returns an access token and ID token
  7. The Web Application sends the access token to the Identity Microservice’s UserInfo endpoint
  8. The Identity Microservice’s Federated Identity Service matches the application scope to the defined view and returns requested attributes
  9. The Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Web Application

There are several key factors in this flow:

  1. The scope sent to the Identity Microservice is the application, or view, for the requested profile data
  2. The view defined in the Federated Identity Service is application-specific and can be limited to just the profile data needed for the authorized application
  3. Multiple application-specific views can be supported by the Identity Microservice
  4. Authentication can be easily mapped back to the user’s profile repository by the Federated Identity Service allowing client web applications to completely delegate authentication to the microservice


Server-Driven Flow

While similar to the user-driven Web Application flow, no user interaction is present for this transaction. The Server-driven flow allows for backend access to profile data. In this case, the server is being authenticated and not the user.

The following diagram breaks down the Server-driven flow:

  1. Server sends client credentials and application scope to the Authorization Server
  2. Authorization Server returns an access token and ID token
  3. Server sends the access token to the UserInfo endpoint
  4. Federated Identity Service matches the application scope to the defined view and returns requested attributes
  5. Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Server

This allows the server to access the same profile data as defined for a Web Application. Additionally, the same views in the Federated Identity Service can be leveraged, if desired, for both Servers and Web Applications.

The Identity Microservice allows for powerful, yet lightweight access to all the needed profile data in an efficient manner. This microservice can provide what is needed at the core of all applications, and for the Server-driven flow can even be used for transaction-specific data unrelated to users. As the world moves toward the model of easily consumable services, the Identity Microservice must be one of the main considerations when designing an application.