# Authentication

The right model depends on how customer identity is established in your system.

Cover Genius configures authentication during onboarding. Partners provide credentials and endpoints — no authentication code runs on the partner side.

### OAuth 2.0 consent

Use this model when the journey needs to access customer data from your system.

**How it works:**

{% code overflow="wrap" expandable="true" %}

```mermaid
sequenceDiagram
    participant P as Partner
    participant J as Journey
    participant CG as Cover Genius

    J->>P: Redirects customer to OAuth authorization URL
    P->>J: Customer grants consent, redirects back with authorization code
    J->>CG: Passes authorization code
    CG->>P: Exchanges code for token
    P->>CG: Returns access token
    CG->>P: Fetches customer data
    P->>CG: Returns customer data
    CG->>J: Populates journey
```

{% endcode %}

**What you provide during onboarding:**

* **OAuth authorization URL** — the URL where customers log in and grant consent
* **OAuth scopes** — the permissions the Cover Genius backend requests
* **Client credentials** — client ID and secret for the token exchange
* **API endpoint** — the URL where the Cover Genius backend fetches customer data using the token

{% hint style="info" %}
The token exchange and data retrieval happen server-to-server. No PII passes through the browser or URL parameters.
{% endhint %}

### SSO via Auth0

Use this model when customers arrive at the journey already authenticated through your identity provider.

**How it works:**

{% code overflow="wrap" expandable="true" %}

```mermaid
sequenceDiagram
    participant P as Partner
    participant J as Journey
    participant CG as Cover Genius

    J->>CG: Customer opens journey, validates existing session via Auth0
    CG->>P: Fetches customer data
    P->>CG: Returns customer data
    CG->>J: Populates journey
```

{% endcode %}

**What you provide during onboarding:**

* **Identity provider details** — SAML or OIDC configuration for federation
* **User attribute mapping** — which identity claims map to customer fields
* **Data API endpoint** — the URL where the Cover Genius backend fetches customer data

{% hint style="info" %}
Cover Genius provisions the Auth0 integration during onboarding. No code changes are required on the partner side. Customer data is retrieved server-to-server — no PII passes through the browser.
{% endhint %}

### Unauthenticated

Use this model when no customer login is required. The journey collects customer information directly through forms.

**How it works:**

{% code overflow="wrap" expandable="true" %}

```mermaid
sequenceDiagram
    participant J as Journey
    participant CG as Cover Genius

    J->>J: Customer opens journey, fills in details via forms
    J->>CG: Stores data in journey session
```

{% endcode %}

This model is common for regulated partners (e.g., banks) where customer data cannot be passed through embedded widgets and must be collected within the Cover Genius-hosted experience.

### Summary

| Model             | Customer login?                | Partner provides                 | Best for                             |
| ----------------- | ------------------------------ | -------------------------------- | ------------------------------------ |
| OAuth 2.0 consent | Yes, on partner's platform     | OAuth credentials + API endpoint | Accessing partner-held customer data |
| SSO via Auth0     | Transparent (existing session) | Identity provider config         | Pre-authenticated customers          |
| Unauthenticated   | No                             | Nothing (for auth)               | Open access, regulated partners      |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://partner-docs.covergenius.com/home/xcover-journeys/integration/authentication.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.