---
title: "Thales Configuration"
slug: "thales-configuration"
updated: 2026-05-24T15:42:11Z
published: 2026-05-24T15:42:11Z
canonical: "docs.plainid.io/thales-configuration"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Thales Configuration

The Thales OneWelcome Authorizer enables secure, dynamic token enrichment through webhook-based integration. It supports both OIDC and SAML flows and introduces the following capabilities.

Successful implementation depends on validating webhook contracts and aligning with Thales-specific behavior for payload structure, response handling, and error management.

> Configuration steps depend on the Thales OneWelcome admin interface.

## Defining the Webhook

Configure one of the following webhooks:

- Access Token Webhook
- SAML Assertion Webhook

| Parameter | Value |
| --- | --- |
| Endpoint URL (The PlainId IdP service host in PAA) | `https://{your-address}/idp-hook/thales/{flow}` |
| Method | `POST` |
| Authentication | Bearer token with the JWT managed by Thales |
| Content-Type | `application/json` |

## PlainID Endpoint Configuration

### Endpoint Structure

```
POST /idp-hook/thales/{flow}
```

Where `{flow}` can be one of the following values:

- `access-token`
- `saml-assertion`

## Request Handling

### Headers

| Header | Description |
| --- | --- |
| Authorization | Bearer JWT from Thales |
| Content-Type | `application/json` |

## JWT Validation

PlainID must validate the incoming token before processing the request.

**To validate the JWT:**

1. Extract the JWT from the `Authorization` header.
2. Decode the token and read the `iss` claim.
3. Retrieve the OpenID configuration from:

```
{iss}/.well-known/openid-configuration
```
4. Extract the `jwks_uri` value.
5. Validate the token signature by using the JWKS.
6. Validate the token claims:
  - Default `client_id` is `onewelcomeAccessWebHookClient`.
  - `scope` must start with `onewelcome_webhooks`.
  - The token must not be expired.

### Example JWT Payload

```
{
  "aud": "https://webhook-test.com/...",
  "sub": "onewelcomeAccessWebHookClient",
  "scope": "onewelcome_webhooks onewelcome_webhook_jan",
  "iss": "https://playground2.gw.test.onewelcome.net/oauth",
  "exp": 1768297733,
  "client_id": "onewelcomeAccessWebHookClient"
}
```

## Thales-Specific PlainID Configuration

The following configuration is required for Thales OneWelcome integrations:

```
idpConfig:
  useIncomingJWTForPDP: true
  expectedClientID: onewelcomeAccessWebHookClient
  scopePrefix: onewelcome_webhooks

idToken:
  verify: true
  iss: https://{{address}}.onewelcome.net/oauth
  aud: https://{{address}}/idp-hook/1.0/thales/access-token

identityAttributes:
  - name: firstName
    path: $.firstName
```

### Configuration Notes

| Parameter | Description |
| --- | --- |
| `useIncomingJWTForPDP` | Uses the JWT received from Thales for PDP evaluation. |
| `expectedClientID` | Expected `client_id` value in the incoming JWT. |
| `scopePrefix` | Required prefix for webhook scopes. |
| `idToken.verify` | Enables JWT validation. |
| `idToken.iss` | Expected JWT issuer. |
| `idToken.aud` | Expected JWT audience value. |
| `identityAttributes` | Defines Attributes extracted from the incoming request payload by using JSONPath expressions. |

> `idToken` configuration already exists in the platform and should not be duplicated unless customization is required.

## Request Payload

The request payload structure depends on the webhook type configured in Thales OneWelcome.

### Access Token Webhook Example

```
{
  "userClaims": {
    "firstName": "John"
  }
}
```

### SAML Assertion Webhook Example

```
{
  "userAttributes": {
    "firstName": "John"
  }
}
```

## Thales Request Attribute Mapping

In Thales OneWelcome, user-related Attributes are sent differently depending on the integration type:

| Flow Type | Request Section |
| --- | --- |
| SAML Assertion Webhook | `userAttributes` |
| Access Token Webhook | `userClaims` |

The JSONPath for each Attribute must be configured and included in the request so PlainID can extract and evaluate the relevant values.

### Example Attribute Mapping

```
identityAttributes:
  - name: firstName
    path: $.firstName
```

In this example:

- `name` defines the Attribute name used by PlainID.
- `path` defines the JSONPath location within the incoming Thales request payload.

PlainID resolves the configured JSONPath and injects the Attribute into the Policy evaluation context.

## Generic Request Structure

The exact request payload structure from Thales should be validated against the official documentation before production deployment.

### Assumed Structure

```
{
  "user": { ... },
  "client": { ... },
  "context": { ... },
  "tokenType": "access_token | saml_assertion"
}
```

### Request Payload Parameters

| Parameter | Type | Description |
| --- | --- | --- |
| `user` | Object | Contains user-related Attributes used for Policy evaluation. The structure is defined by Thales. |
| `client` | Object | Contains client or application-related Attributes initiating the request. |
| `context` | Object | Contains additional contextual data such as session details, Environment data, or request metadata. |
| `tokenType` | String | Indicates the token type. Possible values: `access_token` or `saml_assertion`. |

### user Object

| Parameter | Type | Description |
| --- | --- | --- |
| `id` | String | Unique identifier of the user. |
| `attributes` | Object | Key-value pairs representing user Attributes. |

### client Object

| Parameter | Type | Description |
| --- | --- | --- |
| `client_id` | String | Identifier of the client application. |
| `name` | String | Name of the client application. |

### context Object

| Parameter | Type | Description |
| --- | --- | --- |
| `ip` | String | IP address of the request origin. |
| `sessionId` | String | Identifier of the user session. |
| `timestamp` | String | Request timestamp in ISO format. |

## Response Format

PlainID returns authorization claims to be injected into the token or assertion.

### Example Response

```
{
  "claimPortalRole": ["Administrator"],
  "DepartmentManagerLevel": ["Senior"]
}
```

### Response Behavior

- Each key-value pair is added as a claim.
- Claims are included in one of the following outputs:
  - Access Token for OIDC flows.
  - SAML Assertion for SAML flows.

## Error Handling

Use the following recommended behavior:

| Scenario | Recommended Handling |
| --- | --- |
| Invalid JWT | Reject the request with `401 Unauthorized`. |
| Authorization failure | Return empty claims or an error response based on the integration requirement. |
| Timeout | Handle according to confirmed Thales behavior. |

> Thales fallback behavior must be confirmed before production deployment.