Authentication

The IAM block abstracts the complex functionality of authentication with simple concepts outlined below. The key concepts are:

1. User Types
2. Providers
3. Realms
4. Tokens

User Types

IAM block on kis.ai supports five types of principals, or user types, ensuring comprehensive and flexible access control. This diverse range of principals allows for precise and secure management of various entities interacting with the system.

User Type	Description	ID Prefix
Users	Regular end-users accessing applications and services	U
Delegates	Regular end-users that temporarily do specific tasks on behalf of another user	D
Agents	Autonomous and intelligent agents performing tasks on behalf of users	A
Bots	Intelligent bots providing automated responses, interactions and assisting regular end-users	B
Services	Internal services that require access to other services or resources within the ecosystem	S

Providers

IAM block on kis.ai supports a wide range of authentication providers to ensure seamless and secure user access. This block allows two primary types of Authentication Provider types.

1. Delegate, where authentication is delegated to another provider like Azure AD or Okta, and the IAM block only forwards the authentication request to these providers and takes the success token from them to give a signed JWT.
2. Managed, where the full cycle of authentication and generating the JWT token is taken care of by the IAM block itself.

Delegate providers, like O365, Google and Okta are useful in enterprises with SSO (Single Sign On) requirements. Social logins, which are also another type of Delegate providers, are useful in B2C product scenarios where you do not want to add friction of creating a user account with explicit username and password.

Managed providers are useful when you want to manage the full life cycle of authentication and your users do not want to create a separate login for your product.

Provider	Authn Type	Description
Cloud Identity	Delegate	Google, Microsoft, Okta, Auth0, Cognito
OAuth2	Delegate	Most OAuth2 providers, Ory Hydra
Social	Delegate	Facebook, X, LinkedIn
SAML	Delegate	SAML 2.0
Challenge	Managed	traditional user id and password
OTP	Managed	OTPs are sent to user over SMS, Email and WhatsApp
Magic Link	Managed	Links are sent to user over SMS, Email and WhatsApp. Usually easier than OTP, with remote login options
WebAuthn	Managed	Password-less Login
Passkey	Managed	Password-less Login

MFA is supported for all managed providers, by IAM block. In case of delegate providers, MFA is enforced and managed by the provider itself.

Configuring Providers

Providers are set up for each product by adding them in iam/providers.yaml. You can use Anica to generate the providers yaml with common providers. Please do note all Delegate Providers need specific app keys and secrets from your admin.

Here three providers have been configured, and end-users can use any one of them to log in to your product.

iam/providers.yaml

providers:
- name: password
  type: challenge
- name: otp
  type: otpsms
- name: o365
  type: oauth
- name: magiclink
  type: magic
  template: magictemplate

Realm

Realms are used to separate different types of users and provide them with distinct authentication methods. This approach ensures tailored security and user experience for various user groups within an application.

Example: Food Delivery App

• Employees: Authenticated via OAuth, allowing secure and efficient access to internal systems.
• Partners: Delivery partners authenticated with magic links sent to their email for a seamless and secure login experience.
• Customers: Verified using OTP (One-Time Password) sent via SMS, ensuring quick and easy access to the app.

Configuring Realms

Realms are set up for each product by adding them in iam/realms.yaml.

iam/realms.yaml

realms:
  users:
    default: true
    active: true
    providers:
    - o365
  customers:
    providers:
    - otp
  partners:
    providers:
    - magiclink
  owners:
    providers:
    - password

IAM APIs

Most blocks in kis.ai are headless by default and provide APIs for every action.

Login

With password

API flow of Login with password

(Sequence diagram omitted, not extractable as text. It shows a client sending {email, password} to IAM and receiving {refresh, token}.)

POST /account/auth/password

Request

{
  "email": "[email protected]",
  "password": "abc$123"
}

Response

{
  "refresh": "N0UxfaUcLj...",
  "token": "eyJhbGciOiJ..."
}

With Remote Magic Link

Sometimes users need to log in on machines where they do not want to enter a password, but want to log in for a short while.

API flow of Remote Magic Link

(Sequence diagram omitted, not extractable as text. It shows a user on desktop and the same user on mobile interacting with the IAM service to complete a remote magic link login.)

Step 1: Request the magic link from the insecure computer with just an email.

POST /account/auth/magiclink

Request

{
  "email": "[email protected]",
  "remotelogin": true
}

Response

{
  "remotechecktoken": "343535345",
  "message": "magic link generated successfully and sent to your email"
}

Step 2: The user clicks the magic link on their secure mobile device.

The javascript in the browser of the insecure computer is polling the server for login for an access token.

POST /account/auth/magiclink

Request

{
  "email": "[email protected]",
  "remotechecktoken": "343535345"
}

Response

{
  "refresh": "N0UxfaUcLj...",
  "token": "eyJhbGciOiJ..."
}