Hva du må vite om Okta Authorization Servers
Okta tilbyr forskjellige servere for autentisering for OAuth 2.0 og OpenID Connect (OIDC). Alle tilgjengelige alternativer er dessverre ikke synlige gjennom administrasjonspanelet. Hovedforskjellen mellom autoriseringsserverne er deres evne til å tilpasse seg, spesielt når det gjelder omfang og krav, samt tilgjengelighet gjennom Okta-lisensiering.

Andreas Faltin
05. oktober 2021
Andreas er Cloud Architect i Cloudworks og Okta Technical Champion. Han hjelper kunder på deres digitale identitetsreise ved å designe og implementere komplekse IAM-løsninger. Disse er i stor grad automatiserte for å oppnå mest mulig innvirkning med minimal brukerfriksjon.
Org Authorization Server
Enhver Okta instans kommer med en såkalt Org Authorization Server. Dette er ikke synlig i administrasjonspanelet, men vil alltid være tilgjengelig via endepunktene:
Org Authorization Servers kan ikke tilpasses, men tilbyr likevel et bredt spekter av krav og omfang som er egnet for de fleste applikasjoner. Org Authorization Server støtter for eksempel gruppeomfang og krav, slik at programmer som krever rolle- eller gruppetilordningsinformasjon, ikke krever en egendefinert autorisasjonsserver.
I Okta OIDC-appen kan ID-tokenet konfigureres til å vise bare grupper som er relevante for appen. I eksemplet nedenfor vil alle Okta-grupper som begynner med "OIDCApp_Role_", bli presentert i gruppekravet for ID-tokenet.
Relevant Okta-dokumentasjon:
https://developer.okta.com/docs/concepts/auth-servers/#org-authorization-server
Custom Authorization Servers
Instanser med API Access Management-lisensen SKU vil få opp alternativet for “Authorization Servers” i sitt Okta administrasjonspanel under Security → API. Som standard er det alltid definert en Default Custom Authorization Server.

Figur 1 - Default Custom Authorization Server - IKKE Org Authorization Server
Default Custom Authorization Server kan brukes som referanse for andre autoriseringsservere eller for å teste ulike utviklingsapplikasjoner. Den er allerede forhåndskonfigurert med standard omfang og krav.
Enhver tilpasset autorisasjonsserver kan konfigureres i sin helhet. Det vil derfor ikke være nødvendig med en individuell autoriseringsserver for hver app, men det kan likevel være fornuftig å skille ulike konfigurasjoner eller bruke caser til separate endepunkter for autorisering.
Endepunktene for Default Custom Authorization Server er:
For enhver ekstra Custom Authorization Server:
Siden Default Custom Authorization Server er en del av lisensen API Access Management, vil alle brukere som er tildelt en applikasjon som bruker denne autoriseringstjeneren, inkluderes i API Access Management-lisensen. Hvis du kun trenger API Access Management for et utvalg av brukerne dine, må du sørge for at alle standard OIDC-apper bruker Org Authorization Server.
Alle dine egendefinerte autorisasjonstjenere (også standard) bør begrenses til de nøyaktige appene de kreves for. Dette hovedsakelig for å øke sikkerheten, men også for å unngå ytterligere lisenskostnader siden API -lisensen beregnes ut fra mengden brukere med potensiell tilgang til en autorisasjonsserver.

Når skal du bruke hvilken autoriseringsserver?
I utgangspunktet gir alle autorisasjonsservere de samme mulighetene for OAuth og OIDC-autorisering. Ved å svare på følgende spørsmål vil du kunne avklare hvilken du skal bruke og i hvilken situasjon:
→ Er Org Authorization Server tilstrekkelig?
Det er den som regel. Siden den ikke krever noen ytterligere lisenser for brukerne, bør dette være førstevalget.
→ Trenger jeg ytterligere omfang, krav eller andre tilpasninger, som for eksempel et spesielt publikum?
I dette tilfelle vil en tilpasset autorisasjonsserver være det rette alternativet. Tilgangstokenene fra Org Authorization Server kan heller ikke valideres. Hvis appen din krever dette, må du ha en tilpasset autorisasjonsserver.
→ Trenger jeg å opprette en ekstra tilpasset autorisasjonsserver?
Det avhenger av retningslinjer og krav i organisasjon din. Noen har separate interne og eksterne systemer, mens andre har dedikerte servere for tilpasset autorisasjon for hver applikasjon.
Det er derfor viktig å sørge for at dersom du endrer en eksisterende autoriseringsserver, så vil dette ødelegge alle eksisterende applikasjoner. Antallet autoriseringsservere er ikke lisensiert, så det er mulig det gir mest mening å begynne med en dedikert testautoriseringsserver først, for å så legge til konfigurasjonen til en eksisterende autoriseringsserver når du går over til produksjon.
Okta har også en oversikt over mulighetene i autoriseringsserverne.