Validere tokens

Grovkornet validering av JWT-tokens kan gjøres med introspect-endepunktet i Texas

Finkornet validering må gjøres i applikasjonskode

Texas validerer kun JWT'ens gyldighet opp mot relevant identity provider. Du må fremdeles utføre relevant validering for din applikasjon i egen applikasjoskode, f.eks validering av claims som scope, aud, consumer, supplier, client, groups, med mer.

Nødvendig oppsett

For å få Texas som sidecar må du spesifisere "texas" som tilgjengelig sidecar-tjeneste for din Skiperator-applikasjon. I tillegg må Texas ha nødvendig konfigurasjon og nettverksåpning for å nå den aktuelle identity provideren. Dette gjøres med en SecurityConfig-ressurs.

Du bør kun aktivere validering for de(n) identity provideren(e) som er relevant for din applikasjon. Texas sidecar'en er avhengig av å hente JWKS-endepunkter for de identity providerene som er aktivert ved oppstart. Dersom du aktiverer validering for en identity provider som ikke er relevant for din applikasjon, introduserer du altså en unødvendig avhengighet og risiko for at Texas sidecar'en ikke starter opp ved nedetid hos den aktuelle identity provideren.

Du finner API-spesifikasjon inkludert detaljerte feltbeskrivelser for SecurityConfig-ressursen i API-dokumentasjonen.

Tokenx

Eksempel på SecurityConfig for Tokenx-validering

apiVersion: security.skip.kartverket.no/v1alpha1
kind: SecurityConfig
spec:
  applicationRef: my-app
  tokenx:
    enabled: true
  ...

Dette vil opprette ServiceEntry som tillater trafikk mot TokenX-tjenesten på SKIP, samt konfigurere Texas sidecar'en til å støtte validering av TokenX-tokens.

Maskinporten

Eksempel på SecurityConfig for Maskinporten-validering

apiVersion: security.skip.kartverket.no/v1alpha1
kind: SecurityConfig
spec:
  applicationRef: my-app
  maskinporten:
    enabled: true
  ...

Dette vil opprette ServiceEntry som tillater trafikk mot Maskinporten, samt konfigurere Texas sidecar'en til å støtte validering av Maskinporten-tokens.

Entra ID

Eksempel på SecurityConfig for Entra ID-validering

apiVersion: security.skip.kartverket.no/v1alpha1
kind: SecurityConfig
spec:
  applicationRef: my-app
  entraid:
    enabled: true
  ...

Dette vil opprette ServiceEntry som tillater trafikk mot Entra ID, samt konfigurere Texas sidecar'en til å støtte validering av Entra ID-tokens.

ID-porten

Eksempel på SecurityConfig for ID-porten-validering

apiVersion: security.skip.kartverket.no/v1alpha1
kind: SecurityConfig
spec:
  applicationRef: my-app
  idporten:
    enabled: true
    allowedAudience:
      <enten value eller valueFrom>
  ...

Dette vil opprette ServiceEntry som tillater trafikk mot ID-porten, samt konfigurere Texas sidecar'en til å støtte validering av ID-porten-tokens. Validering av ID-porten-tokens krever audience-restriksjon, og dette må spesifiseres enten direkte i value-feltet, eller ved å referere til en eksisterende ConfigMap eller Secret med valueFrom-feltet.

Du kan lese mer om audience-restriksjon i ID-porten-dokumentasjonen.

Ansattporten

Eksempel på SecurityConfig for Ansattporten-validering

apiVersion: security.skip.kartverket.no/v1alpha1
kind: SecurityConfig
spec:
  applicationRef: my-app
  ansattporten:
    enabled: true
    allowedAudience:
      <enten value eller valueFrom>
  ...

Dette vil opprette ServiceEntry som tillater trafikk mot Ansattporten, samt konfigurere Texas sidecar'en til å støtte validering av Ansattporten-tokens. Validering av Ansattporten-tokens krever audience-restriksjon, og dette må spesifiseres enten direkte i value-feltet, eller ved å referere til en eksisterende ConfigMap eller Secret med valueFrom-feltet.

Du kan lese mer om audience-restriksjon i ID-porten-dokumentasjonen (Ansattporten fungerer på samme måte som ID-porten her, men har ingen egen dokumentasjon).

Request

POST <TEXAS_URL>/api/v1/introspect
Content-Type: application/json

Body:
{
  "identity_provider": "<identity provider, f.eks entra_id>",
  "token": "<access-token>"
}

Gyldige verdier for identity_provider-feltet er: entra_id, tokenx, maskinporten, idporten og ansattporten.

Respons

Responsen vil være på json-format. Dersom tokenet ikke er gyldig vil active-feltet i responsen være false, og error-feltet vil inneholde en tekstbeskrivelse av feilen. Eksempel:

{
  "active": false,
  "error": "Token is expired"
}

Dersom tokenet er gyldig vil active-feltet i responsen være true, og responsen vil inneholde alle relevante claims i tokenet. Eksempel:

{
  "active": true,
  "aud": ...,
  "client": ...,
  "iat": ...,
  "exp": ...,
  ...
}