Authentication

IAM block of provides 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. These 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 takes forwards the authentication request to these providers and takes the success token from them and give a signed a JWT
2. Managed where the full cycle of authentication and generating the JWT token is taken care 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 full life cycle of authentication and your users do not want to create a separate login for your product.

Provider	Authn Type	Description
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

Provider	Authn Type	Description
Cloud Identity	Delegate	Google, Microsoft, Okta, Auth0, Cognito
OAuth2	Delegate	Most OAuth2 providers, Ory Hydra
Social	Delegate	Facebook, X, LinkedI
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 setup for each product by adding them in the iam/providers.yaml. You can use Anica to generate the providers yaml with common providers. Please do note all Delegate Providers need to specific app keys and secrets from your admin.

Here three providers have been configured, and end-users can use any one of them to login into 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 setup for each product by adding them in the 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

POST /account/auth/password

Request

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

Response

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

with Remote Magic Link

Sometimes users need to login into machines that do not want to enter password, but want to login for a short while.

API flow of Remote Magic Link

Step 1: Request the magic link from insecure computer with just 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: User clicks magic link on their secure mobile

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

POST /account/auth/magiclink

Request

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

Response

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