Autentisering
Hver offentlige-API-forespørsel bærer et legitimasjonspar — nb_pub_* (offentlig nøkkel) + nb_sec_* (hemmelighet). Hemmeligheten sendes som et Bearer-token. Legitimasjonen er begrenset til én enkelt org + en fast scope-katalog.
Utstede legitimasjon
- Logg inn på organisasjonen din på app.nexbasira.com.
- Gå til Admin → API credentials.
- Klikk Issue credential, velg et navn + scopes, bekreft.
- Kopier paret
nb_pub_*+nb_sec_*. Hemmeligheten vises nøyaktig én gang. Lagre den i secrets manager-en din umiddelbart — vi beholder bare en SHA-256-hash på vår side.
Bruke legitimasjonen
Authorization: Bearer nb_sec_AbCdEf... Den offentlige nøkkelen (nb_pub_*) identifiserer legitimasjonen i loggene våre og vises i webhook-leveransenes NB-Credential-Id-header. Hemmeligheten autentiserer.
curl https://app.nexbasira.com/api/v1/public/sessions \
-H "Authorization: Bearer nb_sec_..."Scope-katalog
Hver legitimasjon opprettes med et eksplisitt scope-sett. Forespørsler utenfor disse scopene returnerer 403. Scope-katalogen er fast (ingen egendefinerte scopes i v1):
| Scope | Gir tilgang til |
|---|---|
sessions:read | List + hent økter |
sessions:write | Opprett økter + avslutt dem |
participants:read | List deltakere i en økt |
participants:write | Generer feltbruker-invitasjoner |
evidence:read | List + hent bevisrader + signerte nedlastings-URL-er |
recordings:read | Les metadata for opptaksartefakter + nedlastings-URL-er |
audit:read | Les den per-økt audit-kjeden + TSA-forankringskoordinater |
webhooks:read | List registrerte webhook-endepunkter + leveringslogg |
webhooks:write | Registrer / roter-hemmelighet / slett webhook-endepunkter |
branding:read | Les org-merkevare (logo / farger / PDF-bunntekst) |
branding:write | Endre org-merkevare |
org:read | Les org-metadata |
whiteboards:read | List tavler per økt |
Rotering
For å rotere uten nedetid:
- Utsted en ny legitimasjon med samme scope-sett.
- Deploy den nye hemmeligheten til applikasjonen din.
- Verifiser at den nye legitimasjonen tar trafikk (Admin → API credentials viser tidsstempel for sist brukt).
- Myk-tilbakekall den gamle legitimasjonen. Eksisterende forespørsler som bruker den får 401; revisjonssporet for tidligere kall forblir intakt.
Verifisering i konstant tid
På backend-en lagres hemmeligheter som SHA-256(secret + SECRET_KEY_pepper) og sammenlignes i konstant tid (hmac.compare_digest). En lekket hash-dump kan ikke brute-forces til klartekst uten også å knekke pepper-en.
Hva denne legitimasjonen IKKE gir tilgang til
- SPA-administratortilgang — det er separat (operatørinnlogging + RBAC).
- Feltside-deltakelse — de bruker engangs signerte URL-er generert via
sessions.invite(). - SCIM-provisjonering — bruker et separat per-org bearer-token, se SCIM-provisjonering.
- Webhook-signering — det gjøres med den per-endepunkt
whsec_*-hemmeligheten, se Webhooks.
Revisjonsspor
Hvert API-kall logges med legitimasjonens offentlige nøkkel + endepunktet + status. Operasjoner som endrer tilstand skriver i tillegg revisjonsrader i den berørte org-en. Admin kan se legitimasjonens aktivitet på Admin → API credentials → [credential] → Activity.