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.