> For the complete documentation index, see [llms.txt](https://docs.hos.accessacloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hos.accessacloud.com/atreemo-api/get-started/permissions.md).

# Permissions

Separate Atreemo method permissions, user identity and brand access

{% hint style="warning" %}
**Beta, runtime validation pending.** Authentication, API-method permission and brand access are separate decisions. The public catalogue defines no universal OAuth scope list or permission-provisioning API. Do not invent one scope or named role per endpoint.
{% endhint %}

**Published** evidence is the public Atreemo guide/collection 1.34.0.0. **Source-verified** evidence is read-only inspection at commit `ea9cb106e13aa4b9b92c01d090118742b44dd470`. Source is not proof of target behaviour.

## Published behaviour

* Atreemo owners/support provide the login and password used for native token authentication.
* Customer, HotelBooking, LoyaltyPoint, LoyaltyProgram and SurveyApi documentation lists `403 Forbidden` for method access denial. A valid token does not grant every method.
* Customer, LoyaltyPoint and LoyaltyProgram use business error `3` for unauthorised or missing brand selection.
* `GET /api/User/GetAllowedBrands` is the published brand-discovery operation. Brand requirements remain operation-specific.

## Source-verified responsibilities

| Component                                                       | Responsibility                                                                                                                                  |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `Startup.Auth.cs:236–260`; `ApplicationOAuthProvider.cs:59–220` | Registers native `/Token` issuance and implements two build-dependent password-grant branches. Effective deployment settings remain unverified. |
| `ApiAccountController.cs:140–171,173–251`                       | Resolves the authenticated caller to an Atreemo membership user and `UserID`; it is not the native token issuer.                                |
| `Tools/Functions.cs:3408–3417`                                  | `IsUserAuthorized` compares an API URL identifier with the user's allowed URL list, or accepts its internal-call/Access Identity branches.      |
| `ProfilesHelper.cs:2084–2107`                                   | Loads allowed `Url` strings using `[Atreemo].[API_GetAPIAccessByUserID]` and `UserID`; procedure and live grants were not inspected.            |
| `GlobalHelper.cs:1668–1769`                                     | Selects authorised brands and checks a requested brand for callers using this helper.                                                           |

`UserID` identifies the authenticated Atreemo user. `CtcID` identifies a contact/customer. They are not interchangeable.

## Method permission is not a universal scope

`IsUserAuthorized` performs an exact, case-sensitive string comparison and receives no HTTP verb. LoyaltyPoint constructs identifiers such as `LoyaltyPoint/<method-name>`; this does not establish identical key construction for every action. The database-backed allowed-URL list and application UI permissions are separate mechanisms.

The OpenAPI `AtreemoBearer` requirement records the published integration flow with no invented scopes. It does not itself grant method or brand access and is not proof that every source action enforces authentication identically.

## Internal and Access Identity branches

The helper can also accept a server-side request-context type containing `controllers`, or a positive Atreemo user resolved from Access Identity claims. The internal branch is not a caller header/query option.

Access Identity middleware is conditionally registered and handles JWTs using OIDC discovery, configured issuer/audience, signing keys and lifetime checks. Its deployment, authority and mappings remain unverified. Source sets `RequiredScope` to an empty string, so it does not establish a public scope catalogue. Do not represent this branch as Hydra, native-password-token issuance or a supported partner onboarding flow.

## Brand selection

For callers using `IsUserAuthorizedToUseBrand`, source establishes:

* One authorised brand: omitted/zero selects it; a different supplied brand fails.
* Multiple authorised brands: a supplied value must be in the list. Omitted/zero is accepted only when the authorised list covers all brands.
* No authorised brands: the check fails.
* No brands configured: this helper returns true without the list check.

These are helper rules, not proof every endpoint uses the helper. Preserve each operation's conditional `BrandID` requirement.

Concrete source differences include LoyaltyPoint method denial as HTTP `403`, brand denial as HTTP `200` with code `3`, and exceptions as `500` (`LoyaltyPoint.cs:47–112,139–214`). ApiOpenAI includes conflicting anonymous/authorised attributes and paths without `IsUserAuthorized`; this is a source/catalogue review finding, not a recommendation for anonymous access.

## Phase 1 gateway behaviour

The caller obtains the native token directly from the approved Atreemo instance. The APIM route forwards `Authorization` unchanged, with no mandatory APIM subscription key. Atreemo retains its own method and brand checks. Gateway routing and endpoint availability require staged release validation.

## Unresolved

* Effective native-authentication branch/provider, lifetime and lockout configuration.
* Live API grants and provisioning behind `API_GetAPIAccessByUserID`.
* Deployed Access Identity settings, claims mapping and catalogue/source conflicts.
* Operation-by-operation permission/error branches beyond the cited call sites.
* Release1.34 contract behaviour on the current non-production Release1.35 environment.

See [Authentication](broken://pages/a92d1423ae54b22743d71e7ab5277f8258a1d52c), [Errors](broken://pages/85e546b61406ff3ffac18f135046c2c4b67841e3), [Customer and loyalty](broken://pages/e5cc6873500f015f794d534a74d94a7c2263f342) and [Testing and support](broken://pages/4ebb976c2c8353fb6080a8cf9f615312b52d4144).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hos.accessacloud.com/atreemo-api/get-started/permissions.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
