> ## Documentation Index > Fetch the complete documentation index at: https://developer.suki.ai/llms.txt > Use this file to discover all available pages before exploring further. # Partner Authentication Flow > Learn how the flow works for Partner authentication. Includes a step-by-step token exchange flow: partner JWT, JWKS validation, Suki token, and authorized SDK requests The authentication flow is primarily used for Partner authentication in SDKs. For provider and user authentication against the Partner APIs, refer to [Provider authentication](/api-reference/provider-authentication) guide. This guide explains how to exchange a Partner Token for a Suki Token. Before you begin, complete the prerequisites in [Partner authentication](/documentation/how-to/partner-authentication) guide, including configuring your JWKS endpoint and generating Partner Tokens. Suki uses federated authentication means that your identity provider authenticates the user and issues a Partner Token (JWT). You send that token to Suki. Suki verifies it using your public keys from the JWKS endpoint and returns a Suki Token. Use the Suki Token to authenticate subsequent SDK and API requests. ## How authentication works **Flow diagram:** Below is a diagram of the authentication flow for Partner Token exchange with Suki. ```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}} flowchart TD Start([User Signs In]) --> IDP[Identity Provider
authenticates user] IDP --> Token[IDP issues
partner token JWT] Token --> Init[Your app initializes Suki SDK
with partner token] Init --> Send[SDK sends partner token
to Suki Backend] Send --> Validate[Suki Backend
validates token
using your JWKS endpoint] Validate --> Check{Token valid?} Check -->|No| Error[Authentication fails] Check -->|Yes| SukiToken[Suki Backend returns
Suki-specific token] SukiToken --> Store[SDK stores
token internally] Store --> Ready[SDK ready for use] Ready --> Feature[User requests Suki feature] Feature --> Call[App calls
SDK method] Call --> Auth[SDK makes authorized request
to Suki Backend] Auth --> Response[Suki Backend
returns result] Response --> Display[SDK returns
result to app] Display --> End([Complete]) classDef authStyle fill:#FFE148,stroke:#D4A017,stroke-width:2px,color:#000000 classDef tokenStyle fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#000000 classDef readyStyle fill:#FFD700,stroke:#D4A017,stroke-width:3px,color:#000000 class IDP,Init,Send,Validate authStyle class Token,SukiToken,Store tokenStyle class Ready readyStyle ``` ## Flow steps Partner signs in to your application using your identity provider. After successful authentication, your IDP issues a JWT token (`partnerToken`). Suki does not handle user logins directly. Your IDP verifies the user's credentials and confirms their identity. The IDP can be a third-party service such as Okta or Azure AD, or a system you built yourself. After successful sign-in, your IDP issues a JWT. In the Suki integration this JWT is the **`partnerToken`** (Partner Token). It must be a standard JWT that Suki can verify with your public keys. **Token requirements:** * Signed with the **RS256** algorithm. * Issued by your identity provider after user authentication. * Includes user identifier claims that Suki can verify. * Includes **`exp`**, **`iss`**, **`aud`**, and a user identifier claim such as **`sub`**, **`email`**, or a custom claim you registered during onboarding. During onboarding you tell Suki which identifier field your tokens use. If a token has multiple identifiers, you specify which one is **primary**. Your application initializes the Suki SDK with the **`partnerToken`** and your **`partnerId`**. The SDK sends these values to Suki's backend for validation. You use your existing authentication system for the user; Suki trusts that system through token exchange rather than creating separate user accounts. The SDK forwards the Partner Token to Suki so the backend can validate it before any Suki feature runs. Suki validates the token as follows: * Uses your **`partnerId`** to find your partner configuration. * Fetches your public keys from your registered JWKS endpoint (or another public-key sharing method you configured during onboarding). * Verifies the token's digital signature with those keys. * Confirms the token has not expired and contains the required claims. If validation succeeds, Suki returns a Suki-specific token. This is the token the SDK uses after the exchange. It is separate from the Partner Token your IDP issued. The SDK stores the Suki-specific token securely (you do not manage it yourself) and automatically includes it in API requests. It refreshes it automatically when needed. After the Suki-specific token is stored, the SDK is ready. Your application can use Suki APIs and SDKs. The SDK handles token management for subsequent calls. When the user requests a Suki feature, your app calls the relevant SDK method. The diagram shows this as the path from a ready SDK into feature usage. The SDK sends an authorized request to the Suki backend using the stored Suki-specific token. You do not pass the Partner Token again on every feature call once the exchange has succeeded and the SDK is managing the Suki token. The Suki backend returns the result of the request. The SDK returns that result to your application, which completes the flow for that feature call. ## Available cookbooks