Det skal du vide om Okta Authorization Servers

Okta tilbyder forskellige servere til autentificering til OAuth 2.0 og OpenID (OIDC). Desværre er alle tilgængelige muligheder ikke synlige via admin-panelet. Den væsentligste forskel mellem autorisationsserverne er deres evne til at tilpasse sig, særligt når det gælder omfang og krav samt tilgængelighed via Okta-licensering.

Andreas Faltin
05. oktober 2021

Andreas er Cloud Architect i Cloudworks og Okta Technical Champion. Han hjælper kunderne på deres digitale identitetsrejse ved at designe og implementere komplekse IAM-løsninger. Disse er i stor grad automatiseret for at opnå størst effekt med minimal brugerfriktion.

Org Authorization Server

Alle Okta instanser leveres med en såkaldt Org Authorization Server. Dette er ikke synligt i administrationspanelet, men vil altid være tilgængeligt via slutpunkterne:

Org Authorization Servers kan ikke tilpasses, men tilbyder ikke desto mindre en bred vifte af krav og omfang, som er egnet til de fleste applikationer. Org Authorization Server understøtter for eksempel gruppeomfang og krav, så programmer der kræver oplysninger om rolle- eller gruppetildeling, ikke kræver en egendefineret autorisationsserver.

Org Authorization Server and supported scopes

I Okta OIDC-appen kan ID-tokenet konfigureres til kun at vise grupper, der er relevante for appen. I eksemplet nedenfor vil alle Okta-grupper som begynder med "OIDCApp_Role_", blive præsenteret i gruppekravet for ID-tokenet.

Org Authorization Server and token configuration

Relevant Okta- dokumentation:
https://developer.okta.com/docs/concepts/auth-servers/#org-authorization-server

Custom Authorization Servers

Instanser med API Access Management-licens SKU vil vise muligheden for “Authorization Servers” i Okta administrationspanelet under Security → API. Som standard er der altid defineret en Default Custom Authorization Server.

Okta-API Figur 1 - Default Custom Authorization Server - IKKE Org Authorization Server

Default Custom Authorization Server kan bruges som reference for andre autoriseringsservere eller til at teste forskellige udviklingsapplikationer. Den er allerede forhåndskonfigureret med standard omfang og krav.

Enhver brugerdefineret autorisationsserver kan konfigureres i sin helhed. Det vil derfor ikke være nødvendigt med en individuel autoriseringsserver for hver app, men det kan alligevel være fornuftigt at adskille forskellige konfigurationer eller bruge user cases til separate autoriserings-slutpunkter.

Slutpunkterne for Default Custom Authorization Server er:

Default-Custom-Authorization-Server-1536x404 For enhver ekstra Custom Authorization Server:

Custom-Authorization-Server-1536x404

Da Default Custom Authorization Server er en del af licensen API Access Management, vil alle brugere, som er tildelt en applikation, der bruger denne autoriseringstjenere, inkluderes i API Access Management-licensen. Hvis du kun har brug for API Access Management til et udvalg af dine brugere, skal du sikre, at alle standard OIDC-apps bruger Org Authorization Server.

Alle dine egendefinerede autorisationstjenester (også standard) bør begrænses til nøjagtig de apps, de er nødvendige for. Dette er primært for at øge sikkerheden, men også for at undgå yderligere licensomkostninger, da API-licensen beregnes ud fra mængden af brugere med potentiel adgang til en autorisationsserver.

Default-policy

Hvornår skal du bruge hvilken autoriseringsserver?

Grundlæggende giver alle autorisationsservere de samme muligheder for OAuth og OIDC-autorisering. Ved at svare på følgende spørgsmål vil du kunne afklare, hvilken du skal bruge og i hvilken situation:

→ Er Org Authorization Server tilstrækkelig?
Det er den som regel. Da den ikke kræver yderligere licenser til brugerne, bør dette være det første valg.

→ Har jeg brug for yderligere omfang, krav eller andre tilpasninger, som for eksempel et specielt publikum?
I dette tilfælde vil en tilpasset autorisationsserver være det rigtige alternativ. Adgangstoken fra Org Authorization Server kan heller ikke valideres. Hvis din app kræver dette, skal du have en brugerdefineret autorisationsserver.

→ Skal jeg oprette en ekstra brugerdefineret autorisationsserver?
Det afhænger af retningslinjer og krav i din organisation. Nogle har separate interne og eksterne systemer, mens andre har dedikerede servere med brugerdefineret autorisation for hver applikation.

Det er derfor vigtigt at sikre, at hvis du ændrer en eksisterende autorisationsserver, så vil dette ødelægge alle eksisterende applikationer. Antallet af autorisationsservere er ikke licenseret, så det er tænkeligt, at det giver mest mening først at begynde med en dedikeret testautorisationsserver, for derefter at tilføje konfigurationen til en eksisterende autoriseringsserver når du går over til produktion.

Okta har også en overblik over mulighederne i autoriseringsserverne.