Identity Providers Architecture

Essentially, there are two 'flows' that enable Identity Providers in K2 Cloud: a SCIM-based flow that allows you to pass user identities from an Identity Provider (IdP) to K2, and an OAuth-based OpenID flow that allows K2 to authenticate users against an Identity Provider. The diagram below illustrates the basic architecture of these flows. In the diagram, notice two different colors: the orange flow represents the SCIM flow where the Identity Provider sends user information to K2, and the blue flow represents the authentication flow when users are authenticated against the Identity Provider when they log into K2.

Identity Providers in K2 Cloud: basic architecture

In this example scenario, there are two sample Identity Providers (IdP): Azure Active Directory (AAD) and Google. Each provider contains a K2 for SCIM App that allows the provider to pass user information to the K2 SCIM v2 REST API. Behind the scenes, a microservice supports the API and pushes user information to a staging database. From there, user information is passed to the K2 environment's database. This 'path' ensures that K2 knows about users in the underlying IdP and can quickly look up information such as user names and email addresses. If user information changes in the IdP, the SCIM app should update the cached user information in the K2 environment's database.

When a user authenticates against the K2 front end (SmartForms Site in this example diagram), K2 uses another microservice, called the Login service, to obtain consent for the user to log on using their credentials from the IdP, based on an OAuth2 OIDC implementation. Once the JSON Web Token (JWT) is retrieved from the IdP, K2 uses the claim mappings and security label to compare the user information in the JWT token to the user data stored in the K2 Database, to validate that the user is indeed known by the K2 system. (The user information should have been populated by the SCIM flow).

Note that the two paths must both work for the authentication to succeed. For example, even though a user may be able to authenticate successfully against the IdP through the OIDC path, if their user information is not stored in the K2 environment's database via the SCIM path, they will not be able to use that K2 environment. Likewise, even though user data may exist in the K2 environment's database via the SCIM flow, the user still needs to successfully authenticate against the IdP before they will be able to use that K2 environment.

Open ID Connect (OIDC) OAuth Flow

When a user authenticates against a secured interface in K2, K2 initiates an OAuth 2.0 consent flow to prompt the user to login and obtain an OAuth token. This token is then used as the authentication token for further interaction with K2.

Behind the scenes K2 leverages IdentityServer4 (an OpenID Connect and OAuth 2.0 framework for ASP.NET) to implement the OIDC authentication and consent flow. The diagram below illustrates the flow when an OAuth token is obtained.

K2 OIDC Authentication and Consent Flow diagram