Skip to main content

Choosing the Right OAuth2 Flow for Corti Integrations

Updated over a week ago

Choosing the Right OAuth2 Flow for Corti Integrations

Whether you're embedding the Corti Assistant in a front-end experience (via iFrame/WebView) or calling Corti’s APIs from a backend service, it's important to use the right OAuth2 grant type for the context.
This guide breaks down the four most common flows, when to use them, and why some are better suited for user-facing apps while others are strictly backend-only.

1. Authorization Code Flow with PKCE (Recommended)

Best for:
Native apps, single-page apps, or any browser-based integration where a user is present — for example, embedding the Corti Assistant into your app.

Why:
This flow is secure, interactive, and doesn’t require a client secret (ideal for public apps). It ensures that:

  • A real user is authenticated

  • Actions are properly attributed

  • Sessions are secure against interception

Use this flow anytime you are embedding the Corti Assistant or building a user-facing integration.

2. Authorization Code Flow (without PKCE)

Best for:
Server-side web applications where you can securely store secrets on the backend.

Why:
It works similarly to PKCE but depends on securely storing a client secret, which is not safe in browser-based or mobile apps.

Use this flow only if:

  • Your app has a secure backend

  • The client secret is never exposed to the user or browser

  • All sensitive OAuth2 actions happen server-to-server

3. Resource Owner Password Credentials (ROPC) Grant (Not Recommended)

Best for:
Controlled, trusted internal environments where redirecting users to a login page isn’t possible.

Why:
This flow allows users to enter their username and password directly into your app instead of authenticating through Corti’s login screen.
However, it is riskier because:

  • Users are trained to share credentials directly

  • It skips important security protections

  • It can be easily misused if not properly secured

Use only if absolutely necessary and only in internal, highly controlled setups.

4. Client Credentials Grant (Not for User-Facing Apps)

Best for:
Backend-to-backend API calls where no user interaction is required.

Why:
This flow authenticates the application itself, not an individual user.

It is appropriate for:

  • Machine-to-machine communication

  • Scheduled background jobs

  • Server-side scripts with no user involvement

Important:
Client Credentials should never be used for embedding Corti Assistant or any integration where a user is expected to interact, because:

  • No user information is passed

  • Audit trails and personalization are broken

  • Security risks are increased

Quick Decision Table

Scenario

OAuth2 Flow to Use

Embedding Corti Assistant in a web app

Authorization Code Flow with PKCE

Secure server-side web app (backend storage)

Authorization Code Flow (no PKCE)

Backend-only system integration (no user)

Client Credentials

Internal apps with no redirect capability

ROPC (only if necessary)

💡For a more technical walkthrough go to docs.corti.ai

Final Guidance

  • Always authenticate real users when they are present (use PKCE).

  • Use Client Credentials only when no user is involved.

  • Avoid using ROPC unless absolutely necessary.

  • Never use Client Credentials for any user-facing experience.

Choosing the correct OAuth2 flow protects your users, your data, and your integration with Corti.

If you're unsure which flow fits your setup, contact Corti Support for guidance.

Did this answer your question?