> For the complete documentation index, see [llms.txt](https://kbase.whitelabel-loyalty.com/developer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kbase.whitelabel-loyalty.com/developer/guides/api-authentication/user-api-access.md).

# User API access

User API access allows you to make authenticated API requests on behalf of a specific end user. This is used whenever the request involves personalized data or actions, such as viewing a user’s points balance or reporting an event.

To use user access, you’ll need to pass a valid **user access token** in addition to your API key.

{% hint style="info" %}
This article explains how to authenticate API requests on behalf of a user when using the **WLL API** directly.

If you’re looking for information on how user login works for the **WLL Loyalty Microsite**, see [2. Microsite authentication](https://kbase.whitelabel-loyalty.com/product/interfaces/white-label-interfaces/loyalty-microsite/loyalty-microsite-setup/2.-microsite-authentication) instead.
{% endhint %}

***

## When to use user access

Use user authentication when:

* Reporting events
* Fetching a user’s wallet or user-specific reward list
* Redeeming a reward for a specific user
* Accessing any user-specific data or actions

***

## Authentication method

To authenticate on behalf of a user, include both headers in your request:

```
X-Api-Key: your-tenant-api-key
Authorization: Bearer user-access-token
```

{% hint style="info" %}
Your API key can be found in the **Loyalty Console > Settings > Tenant** screen.
{% endhint %}

***

## Generating user access tokens

WLL does **not** issue user access tokens directly. You must generate tokens via your own identity provider (IdP), such as:

* Firebase Auth
* Auth0
* Any OIDC-compliant service

WLL validates JWTs signed by your IdP, based on your configured authentication settings.

### Token requirements

Your user tokens must meet the following criteria:

* Format: JWT (per [RFC 7519](https://www.rfc-editor.org/rfc/rfc7519))
* Algorithms: `RS256` (RSASSA-PKCS1-v1\_5 with SHA-256) or `HS256` (HMAC SHA-256)
* Required claims in the payload:
  * `sub` (subject – unique user ID)
  * `iss` (issuer)
  * `iat` (issued at)
  * `exp` (expiration time)

If using `RS256`, your token must also include a `kid` (Key ID) header referencing a key from your [JWKS endpoint](https://www.rfc-editor.org/rfc/rfc7517).

***

## Enabling user auth

To configure user authentication, login to the Loyalty Console and navigate to the **Settings > Tenant** screen. From here, you can specify:

* **Algorithm:** `HS256` or `RS256`
* **Issuer:** The expected value of the `iss` claim
* **Shared Key:** The symmetric key for signing/validating tokens (if using HS256)
* **JWKS URL:** The URL for your JWKS (if using RS256)

Once configured, WLL will begin validating user access tokens from your system.

<figure><img src="/files/F6yNDX5siUK6sfwquZ8s" alt=""><figcaption><p>Specifying user auth config in the Loyalty Console</p></figcaption></figure>

***

## Authorization behaviour <a href="#authorization" id="authorization"></a>

* WLL uses your token for authentication only.
* Authorization is handled internally based on the authenticated user’s account.
* Claims in the JWT (e.g. roles, scopes) are not used for permissions.