Gå til innhold

Connect API – autentisering

Connect API bruker JWT Bearer-token. Pålogging gir et kortlevd access-token og et langlevd refresh-token som fornyer access-tokenet uten ny innlogging.

Flyt

sequenceDiagram
    autonumber
    participant A as App
    participant API as Connect API
    participant B as jhlVismaAPI.Business
    participant DB as ConnectSQL (RefreshTokens)
    A->>API: POST /user/login (brukernavn, passord, ClientID)
    API->>B: User.VerifyUser(...)
    B-->>API: OK + brukerdata
    API->>API: JwtManager.GenerateTokenPair()
    API->>DB: lagre refresh-token (per enhet)
    API-->>A: access-token (kort) + refresh-token (lang) + profil
    Note over A,API: senere, når access-token er utløpt:
    A->>API: POST /api/auth/refresh (refresh-token, CompanyID)
    API->>DB: slå opp + valider (ikke revokert/utløpt)
    API-->>A: nytt access-token
    A->>API: POST /api/auth/logout
    API->>DB: revoker token (denne enhet / alle enheter)

Token-design

Token Levetid Lagring
Access-token (JWT) kort (4 timer i GenerateTokenPair/login/refresh) kun hos klient
Refresh-token langt (3 dager) RefreshTokens-tabell i ConnectSQL_‹selskap›
  • JWT signeres med HMAC-SHA256; claims inkluderer brukernavn, selskap (CompanyID) og brukernivå. Signatur og utløp valideres av JwtManager.GetPrincipal().
  • Refresh-tokenet er kryptografisk tilfeldig (256-bit), URL-trygt, og lagres med CreatedAt/ExpiresAt/LastUsedAt/IsRevoked + IP og User-Agent (per enhet).
  • Beskyttede endepunkter bruker JwtAuthenticationAttribute (Authorization: Bearer …). Noen er åpne (AllowAnonymous) eller bruker egne nøkler — se endepunktsreferansen.

Endepunkter

Endepunkt Verb Auth Gjør
/user/login POST åpen Verifiser bruker, utsted token-par
/api/auth/refresh POST åpen Bytt gyldig refresh-token i nytt access-token
/api/auth/logout POST åpen Revoker token (én enhet eller alle)

Kjente fallgruver (re-innlogging i prod)

Brukere har måttet logge inn flere ganger per dag. Mekanismen finnes i koden — sjekk derfor disse to tingene før man leter videre:

  1. Er /api/auth/refresh faktisk deployet i prod? Tidligere undersøkelse viste at refresh-endepunktet svarte 404 i produksjon selv om koden er på plass. Uten fungerende refresh må appen logge inn på nytt hver gang access-tokenet (4 t) utløper. Verifiser at prod-bygget inkluderer AuthController/RefreshTokenRepository og at RefreshTokens-tabellen finnes i ConnectSQL for selskapet.
  2. Access-token-levetid: Web.config har JwtTokenValidHours = 12, men login og refresh utsteder i praksis 4-timers access-token (accessTokenHours: 4). Vil man ha lengre økter, må enten kallene lese verdien fra config, eller refresh fungere sømløst i bakgrunnen.

Note

Hold JWT-secret, VBS-passord og andre nøkler i Web.config på serveren — aldri i kildekontroll. Se Drift og overvåking.

Relaterte sider