Integration API — autentisering og tenant¶

Autentiseringen skal både bevise hvem klienten er og velge riktig kundedatabase. v1 og v2 løser dette på forskjellige måter.

v2 — OAuth client credentials¶

sequenceDiagram
  participant Client as Klienttjeneste
  participant Entra as Microsoft Entra ID
  participant API as Integration API
  participant Sys as wv_sys
  participant Cache as Minnecache
  participant Tenant as Kundedatabase

  Client->>Entra: Be om token med client_id og secret
  Entra-->>Client: JWT med tid og azp/appid
  Client->>API: /api/v2 + Bearer-token
  API->>API: Valider issuer, audience, signatur og levetid
  API->>Cache: Slå opp tenant + klient
  alt Ikke i cache
    API->>Sys: Finn aktiv mapping i wv_OAuthTenantMapping
    Sys-->>API: DomainDB og ev. SQL-bruker
    API->>Cache: Cache connection string i 30 min
  end
  API->>Tenant: Utfør fagoperasjon
  Tenant-->>Client: ApiResponse

OAuthMiddleware leser tenant fra tid og klient fra azp, appid, aud eller client_id. Oppslaget bruker kombinasjonen AzureTenantId + AzureClientId når klient-ID finnes.

Kontroll	Feilresultat
Token mangler eller JWT-validering feiler	`401`
`tid`/fallback-claim kan ikke finnes	`403`
Ingen aktiv tenant/client-mapping	`403`
Mapping finnes, men databasekonfigurasjonen er ugyldig	`403` eller `500`, avhengig av hvor feilen oppstår

v1 — API-nøkkel¶

flowchart TD
  request["Request til /api/v1"] --> header{"X-API-Key finnes?"}
  header -- "Nei" --> unauth["401 API Key is missing"]
  header -- "Ja" --> cache{"Connection string i cache?"}
  cache -- "Ja" --> tenant["Bruk kundedatabase"]
  cache -- "Nei" --> domain["Slå opp domainAPIKey i wv_Domain"]
  domain --> valid{"Aktivt og gyldig oppslag?"}
  valid -- "Nei" --> forbidden["403 Invalid API Key"]
  valid -- "Ja" --> connection["Bygg connection string"]
  connection --> tenant

v1-mappingen bruker wv_Domain.domainAPIKey og feltene for kundedatabase. Connection string caches i 30 minutter.

Klient-onboarding for v2¶

Opprett eller velg API-appregistreringen.
Opprett en separat klientapp for integrasjonen.
Gi klientappen Application permission til API-et og gi admin consent.
Opprett secret eller sertifikat og lagre det i en secrets manager.
Opprett en aktiv rad i wv_OAuthTenantMapping med korrekt AzureTenantId, AzureClientId og DomainDB.
Hent token med scope api://{api-client-id}/.default.
Test et ufarlig GET-kall mot sandkasse.
Verifiser at responsen kommer fra forventet tenant før skrivekall aktiveres.

Cache og endringer¶

stateDiagram-v2
  [*] --> Unmapped
  Unmapped --> Active: Opprett aktiv mapping
  Active --> Cached: Første vellykkede request
  Cached --> Active: Cache utløper etter 30 min
  Active --> Disabled: IsActive settes til 0
  Disabled --> Active: Aktiver mapping

En endring i mapping eller credentials er ikke nødvendigvis synlig for en allerede cachet forbindelse før cacheperioden utløper eller API-prosessen restartes.

Sikkerhetskrav¶

Bruk separate klienter og secrets for test og produksjon.
Legg aldri secret, token eller API-nøkkel i repo, tickets eller skjermbilder.
Roter secret før utløp og ved mistanke om eksponering.
Kontroller både tenant-ID og klient-ID. Tenant-ID alene er ikke tilstrekkelig når flere klientapper ligger i samme Entra-tenant.
Ikke logg Bearer-token. Requestloggeren maskerer auth-headere, men payloaden kan fortsatt inneholde person- eller forretningsdata.

Kildepunkter¶

ePortalIntegrationApi/Program.cs
ePortalIntegrationApi/Middleware/ApiKeyMiddleware.cs
ePortalIntegrationApi/Middleware/OAuthMiddleware.cs
ePortalIntegrationApi/Services/OAuthTenantResolutionService.cs
ePortalIntegrationApi/Services/TenantDatabaseService.cs
Database/Migration_v2_OAuth_MultiClient_Fix.sql