Background

OAuth (Open Authorization) is an open-standard framework for access delegation, allowing applications to securely access a user’s protected resources without exposing their login credentials. By keeping passwords private and limiting access to sensitive information, OAuth improves both security and access management across web, mobile, and desktop applications. OAuth 2.0, the current and most widely adopted version, expands upon the original protocol to support APIs, mobile apps, and connected devices, offering multiple authorization flows tailored to different application types.

Whether you’re embedding the Corti Assistant in a front-end experience (via iFrame/WebView) or calling Corti APIs from a backend service, it’s important to use the right OAuth2 grant type for the given context.

This guide breaks down the four most common OAuth flows, explains when to use them, and why some are better suited for interactive user scenarios while others are strictly backend-only.

OAuth Grant Types

Best for: Native apps, single-page apps, or any browser-based integration where a user is present.

Why: This flow is secure, interactive, and doesn’t require a client secret (ideal for public clients). Proof Key for Code Exchange (PKCE) protects against code interception attacks.

How it works:

  1. Your app redirects the user to Corti’s OAuth2 authorization server.
  2. The user logs in and grants permission.
  3. Corti redirects back with an authorization code.
  4. Your app exchanges the code (with the PKCE verifier) for an access token.

Key Advantages:

  • Secure and suitable for embedded web apps.
  • No client secret is required.
  • Enforces user interaction.
Use this gold standard for Corti Assistant embedded use cases.

2. Authorization Code Flow (without PKCE)

Best for: Server-side web applications where the client secret can be safely stored.

Why: Similar to PKCE, but requires storing a client secret — which is not safe in public or browser-based clients.

Key Concerns:

  • Unsafe for apps where the frontend or iFrame can be inspected.
  • Only acceptable in secure backend environments.
Use only if the OAuth2 flow is entirely server-to-server.

3. Resource Owner Password Credentials (ROPC) Grant (Use with caution)

Best for: Controlled environments with trusted clients (e.g., internal tools).

Why: Allows username/password login directly in the app — but bypasses the authorization server UI.

Risks:

  • Trains users to enter passwords into third-party apps.
  • Easy to misuse, violates best practices.
  • Only viable where UI constraints prevent redirecting (e.g., native kiosk apps without browsers).
This authentication method is not recommended, but sometimes necessary.

4. Client Credentials Grant (Used for API integrations)

Best for: Machine-to-machine API calls where no user is present.

Why: Authenticates the application itself, not an end user.

Why it’s wrong for embedding Corti Assistant:

  • No user context is available.

  • You can’t attribute any actions or documentation to a logged-in user.

  • Doesn’t trigger the UI or login experience.

  • Breaks downstream audit trails, logging, and personalization.

    Not appropriate for user-facing integrations or embedding Corti Assistant.

Final Guidance

Pick the flow that matches your interaction model as offered above. See further details and contact us for support here.

What to Use When:

  • For user-facing or embedded applications (e.g., Corti Assistant in an iFrame):
    Use Authorization Code Flow with PKCE to authenticate the end user securely.
  • For backend-to-backend systems with no user context:
    Use Client Credentials, but only where no user interaction or attribution is needed.
  • Avoid using ROPC unless you’re in a locked-down internal environment with no redirect capabilities.
  • Never use Client Credentials for anything user-facing — it breaks audit trails, personalization, and proper authorization checks.

Additional Reference: