OAuth 2.0 og OpenID Connect

OAuth 2.0 definerer flere måter (kalt «grant types») en klient kan få et tilgangstoken på. Autorisasjonskodeflyten er den vanligste og sikreste for webapplikasjoner.

Dette er en prosess i flere trinn som er utformet for å holde sensitive påloggingsopplysninger (som passordet) borte fra klientapplikasjonen og kun mellom Dem og autorisasjonsserveren.

La oss gå gjennom hvordan denne sikre flyten fungerer, trinn for trinn.

Det hele begynner når klient-applikasjonen trenger tilgang til en brukers beskyttede ressurser (for eksempel kalenderen). Klienten omdirigerer ressurseierens nettleser til autorisasjonsserveren.

Denne omdirigeringen inneholder:

• Klientens ID (client_id)
• Typen tilgang det bes om (scope, for eksempel read:calendar)
• Hvor brukeren skal sendes tilbake (redirect_uri)

Brukeren samhandler nå direkte med autorisasjonsserveren.

På autorisasjonsserveren blir ressurseieren (Dem!) bedt om å logge inn, dersom det ikke allerede er gjort, og deretter om å bekrefte om klient-applikasjonen skal få de forespurte tillatelsene.

Hvis tillatelsen gis, omdirigerer autorisasjonsserveren brukerens nettleser tilbake til klientens forhåndsregistrerte redirect_uri. Denne omdirigeringen inneholder en midlertidig autorisasjonskode som bare kan brukes én gang.

Denne koden er kortvarig og gir ikke tilgang i seg selv.

Nå har klient-applikasjonen autorisasjonskoden. Den sender deretter en direkte forespørsel fra server til server til autorisasjonsserverens token-endepunkt.

I denne forespørselen bytter klienten autorisasjonskoden mot:

• Et Access Token
• Eventuelt et Refresh Token

Denne direkte kommunikasjonen sikrer at klientens hemmelighet (hvis den har en) og tokenene aldri eksponeres i nettleseren.

Etter utvekslingen har klienten to viktige token:

• Access Token: Dette er den faktiske legitimasjonen som brukes for å få tilgang til ressursserveren. Det er vanligvis kortvarig (fra minutter til timer) og inneholder «scopes» som angir hva klienten kan gjøre.
• Refresh Token: Dette er en langvarig legitimasjon som klienten bruker til å hente et nytt tilgangstoken når det nåværende utløper, uten at brukeren må autentisere seg på nytt. Det må lagres sikkert av klienten!

Klienten bruker Access Token til å sende forespørsler til ressursserveren.

OAuth 2.0 er godt egnet til autorisasjon, men tilbyr ikke autentisering av brukere direkte. Det er her OpenID Connect (OIDC) kommer inn!

OIDC er et identitetslag bygget oppå OAuth 2.0. Det gjør det mulig for klienter å bekrefte identiteten til ressurseieren (brukeren) og hente grunnleggende profilinformasjon.

Tenk på det som å legge til et «hvem er De?»-lag på OAuths «hva kan De gjøre?».

Kjernen i OIDC er ID Token. Dette er et JSON Web Token (JWT) som inneholder claims om den autentiserte brukeren.

Vanlige claims omfatter:

• sub (subject): Unik identifikator for brukeren.
• name: Brukerens fulle navn.
• email: Brukerens e-postadresse.
• iss (issuer): URL-en til OIDC-leverandøren.
• aud (audience): Klient-ID-en tokenet er ment for.

Klienten bekrefter signaturen til ID Token for å sikre at det er ekte og ikke er blitt endret.

Godt jobbet! De har lært det grunnleggende om OAuth 2.0 og OpenID Connect.

• OAuth 2.0 er et autorisasjonsrammeverk som muliggjør delegert tilgang til ressurser.
• Det omfatter en ressurseier, klient, autorisasjonsserver og ressursserver.
• Autorisasjonskodeflyten er den sikreste for webapper.
• OpenID Connect bygger på OAuth 2.0 og tilbyr et identitetslag for autentisering av brukere.
• ID Tokens (JWT-er) inneholder claims om brukeridentitet, mens Access Tokens gir tilgang til ressurser.

Det er avgjørende å forstå disse protokollene for å bygge sikre og moderne applikasjoner!