Authorization Code Flow

Husk de fire vigtigste roller i OAuth2:

• Ressourceejer: Brugeren, der giver adgang.
• Klient: Din applikation, der anmoder om adgang.
• Autorisationsserver: Verificerer identitet og udsteder tokens.
• Ressourceserver: Opbevarer de beskyttede data.

I dette flow interagerer de i en bestemt proces med flere trin.

Det hele begynder, når ressourceejeren (brugeren) vil logge ind eller give din klient-applikation adgang.

Din applikation omdirigerer brugerens browser til autorisationsserverens autorisationsendepunkt og medsender flere parametre:

• response_type=code (afgørende!)
• client_id (din apps ID)
• redirect_uri (hvor brugeren skal sendes tilbage)
• scope (de ønskede tilladelser)
• state (af sikkerhedsmæssige årsager, forklaret senere)

Når brugeren er blevet omdirigeret til autorisationsserveren, ser vedkommende en samtykkeskærm.

På skærmen bliver brugeren spurgt, om vedkommende vil give din klient-applikation de ønskede tilladelser, som er defineret af scope.

Brugeren kan derefter vælge at godkende eller afvise anmodningen.

Hvis brugeren godkender, omdirigerer autorisationsserveren brugerens browser tilbage til den redirect_uri, du angav i trin 1.

Denne omdirigerings-URL indeholder nu en autorisationskode, der kun kan bruges én gang, samt den state-parameter, du sendte, f.eks.:

Denne kode er kortlivet og giver ikke direkte adgang til ressourcer.

Det er her, magien sker! Din klient-applikations backend på serversiden modtager autorisationskoden.

Derefter sender den en direkte HTTP POST-anmodning via en bagkanal til autorisationsserverens tokenendepunkt.

Anmodningen indeholder code, redirect_uri, client_id og, ikke mindst, din client_secret, så din applikation kan autentificeres.

Autorisationsserveren validerer anmodningen, især client_secret og code.

Hvis alt er gyldigt, udsteder den et adgangstoken og eventuelt et refresh-token til din klient-applikations backend.

Din applikation kan nu bruge adgangstokenet til at sende anmodninger til ressourceserveren på brugerens vegne.

state-parameteren er en vigtig sikkerhedsforanstaltning mod Cross-Site Request Forgery-angreb (CSRF).

Din klient bør generere en unik, kryptografisk tilfældig streng for hver autorisationsanmodning og medtage den som state-parameter.

Når autorisationsserveren omdirigerer tilbage, medtager den den samme state. Din klient skal derefter kontrollere, at den returnerede state stemmer overens med den, den sendte, så det sikres, at callbacken er legitim.

Autorisationskodeflowet egner sig bedst til:

• Fortrolige klienter: Især webserverapplikationer.
• Klienter med en backend: Hvor client_secret kan opbevares og bruges sikkert.
• Offentlige klienter med PKCE: Mobilapps og SPA'er kan bruge det med en udvidelse kaldet PKCE for øget sikkerhed.

Det er det mest robuste valg, når sikkerhed er afgørende.

Du har nu styr på autorisationskodeflowet!

• Det er det sikreste OAuth2-flow.
• Det er ideelt til fortrolige klienter (apps på serversiden).
• Det bruger en midlertidig autorisationskode, som udveksles til tokens.
• Tokenudvekslingen sker sikkert via en bagkanal (server til server).
• state-parameteren beskytter mod CSRF.

Dette flow danner grundlaget for mange sikre systemer til autentificering og autorisation.