# Okta SSO Last Login Enrichment

{% hint style="warning" %}
**Early Access**: This feature is not enabled by default. Contact your Veza support team to enable the `INTEG_OAA_SSO_LAST_LOGIN` flag for your tenant.
{% endhint %}

Veza can enrich [custom application (OAA)](/4yItIzMvkpAvMVFAamTf/developers/api/oaa.md) users with SSO last login timestamps by correlating Okta sign-in activity with your application's local users. When enabled, each local user in the Veza graph gains a `sso_last_login_at` property showing the last time that user accessed the application through Okta SSO.

This is useful for identifying dormant accounts, auditing access patterns, and supporting access reviews.

## How it works

1. You specify the **Okta Application ID** (`okta_app_id`) for your custom application.
2. Veza matches your OAA local users to Okta users using a configurable matching property (set via the Veza API in Step 2).
3. On each data push, Veza looks up Okta SSO activity for your application and writes the last login timestamp to matching local user nodes.

Enrichment runs in the OAA service after data submission. If Okta activity data is unavailable, the push completes normally without SSO timestamps — no data is lost.

## Prerequisites

* An active Okta integration in Veza with [audit logs enabled](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md#enable-audit-logs-for-okta). Audit log data is the source for `sso_last_login_at` timestamps.
* A custom application (OAA) integration, using either API push or CSV upload.
* Your OAA local users must have `identities` values that match a property on your Okta user profiles (such as email address or a custom attribute).

## Setup

### Step 1: Request feature enablement

Contact your Veza representative or support team and request:

> Enable the `INTEG_OAA_SSO_LAST_LOGIN` feature flag on our tenant.

This flag is Veza-administered and cannot be self-enabled.

### Step 2: Set the matching property configuration

Configure which Okta user property Veza uses to correlate Okta users with your application's local users. You can set this yourself using the Veza API.

{% hint style="warning" %}
`/api/private/` endpoints are not part of the public API contract and may change between releases.
{% endhint %}

The string you pass as `value` specifies which OktaUser attribute to use for identity mapping. The attribute value on each Okta user must match the `identities` field on the linked OAA local users.

* For example, if local users have `identities: ["jane.doe@company.com"]` and OktaUser nodes have `login: "jane.doe@company.com"`, use `login`.
* Custom attributes (e.g., `customprop_employee_id`) are also supported.

To set the property, send a `PUT` request with an API key that has the `admin` or `system_monitoring` role:

```bash
curl -X PUT \
  "https://<tenant>.vezacloud.com/api/private/namespaces/integrations/configurations/okta_sso_user_matching_property" \
  -H "Authorization: Bearer <api_key>" \
  -H "Content-Type: application/json" \
  -d '{"value": "<okta_user_property_name>"}'
```

Replace `<okta_user_property_name>` with the OktaUser property to match on (e.g., `login`, `email`, or a custom attribute such as `customprop_idx_uid`).

To verify the current value:

```bash
curl -s "https://<tenant>.vezacloud.com/api/private/namespaces/integrations/configurations?page_size=100" \
  -H "Authorization: Bearer <api_key>"
```

Look for the `okta_sso_user_matching_property` key in the response.

### Step 3: Find your Okta application ID

Locate the Okta Application ID (`0oa…`) for the application you want to enrich:

1. Log in to your Okta Admin Console.
2. Navigate to **Applications > Applications**.
3. Select the application.
4. Copy the application ID from the URL (format: `0oaXXXXXXXXXXXXXXXX`).

### Step 4: Add the Okta app ID to your custom application

The method depends on how you push data to Veza.

#### API push (JSON)

Add the `okta_app_id` field to your application payload at the application level:

```json
{
  "name": "My Application",
  "application_type": "my_app_type",
  "okta_app_id": "0oaABCDEF1234567890",
  "local_users": [
    {
      "unique_id": "jdoe",
      "name": "Jane Doe",
      "identities": ["jane.doe@company.com"],
      "email": "jane.doe@company.com"
    }
  ]
}
```

* `okta_app_id` (application level): Your Okta Application ID.
* `identities` (user level): One or more identity strings matched against the configured Okta user property.

#### CSV upload

1. Navigate to **Integrations > Custom Application (CSV)**.
2. Enter your Okta Application ID in the **Okta App ID** field in the application configuration form.
3. Upload your CSV as usual, ensuring users have identity values that match their Okta profiles.

{% hint style="info" %}
The **Okta App ID** field in the CSV configuration form is only visible when the `INTEG_OAA_SSO_LAST_LOGIN` feature flag is enabled on your tenant.
{% endhint %}

## Verifying enrichment

After pushing data, verify enrichment is working:

1. Open **Query Builder** in Veza.
2. Query for your custom application's local users.
3. Check the `sso_last_login_at` column on user nodes.

Users whose identities matched an Okta user with SSO activity for your application will have a `sso_last_login_at` timestamp. Users without a match (such as service accounts or users not in Okta) will not have this property — this is expected.

## Behavior notes

* **Matching is case-insensitive.** `Jane.Doe@company.com` and `jane.doe@company.com` are treated as the same identity.
* **First match wins.** If a user has multiple identities, the first one that matches an Okta user is used.
* **Enrichment is non-blocking.** If Okta data is unavailable, the push completes without SSO timestamps. No data is lost.
* **Timestamps reflect Okta access pattern data.** The `sso_last_login_at` value comes from Okta's recorded activity for your specific application.

## Troubleshooting

| Issue                                          | Possible cause                    | Resolution                                                                                                                                                                                                                                                                                                                                                 |
| ---------------------------------------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sso_last_login_at` not appearing on any users | Feature flag not enabled          | Contact Veza support to verify `INTEG_OAA_SSO_LAST_LOGIN` is enabled                                                                                                                                                                                                                                                                                       |
| `sso_last_login_at` not appearing on any users | Matching property not configured  | Use the API in Step 2 to set `okta_sso_user_matching_property`, or contact Veza support to verify it is set                                                                                                                                                                                                                                                |
| `sso_last_login_at` missing on specific users  | Identity mismatch                 | Ensure the user's `identities` values match the OktaUser property values (check casing and email format)                                                                                                                                                                                                                                                   |
| `sso_last_login_at` missing on specific users  | No Okta SSO activity              | The user may not have accessed this application through Okta SSO                                                                                                                                                                                                                                                                                           |
| `sso_last_login_at` missing on specific users  | No audit log activity for the app | Check **Audit Logs** for entries where the identity (GPID) accessed the OktaApp matching your `okta_app_id`. Enrichment only occurs when Veza has recorded SSO activity for that identity and application. This requires [Audit Logs enabled](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md#enable-audit-logs-for-okta) on the Okta integration. |
| **Okta App ID** field not visible in CSV form  | Feature flag not enabled          | Contact Veza support to enable the feature                                                                                                                                                                                                                                                                                                                 |


---

# 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://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/oaa/rest-api/okta-sso-last-login.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.