OAuth2.0, OIDC og SAML

Jeg jobber for tiden mye med testing av applikasjoner med OAuth2 og OIDC og tenkte derfor jeg skulle skrive om det.

I løpet av internetts barndomsdager var det veldig enkelt å dele informasjon mellom tjenester. En tjeneste ville be deg om ditt brukernavn og passord, slik at de kunne logge inn på kontoen din og få informasjonen de ønsket. Det var ingen garanti for at en organisasjon ville holde legitimasjonen din trygg, at tjenesten deres ikke vil få tilgang til mer av din personlige informasjon enn nødvendig.

Ta Yelp, for eksempel. På den tiden, hvis du ville finne vennene dine på Yelp, måtte du:

• Fortell Yelp hvilken e-postleverandør du brukte
• Gi Yelp e-postadressen din
• Gi Yelp e-postpassordet ditt

Yelp trengte at du gav dem all den sensitive legitimasjonen din, slik at de deretter kunne begynne å sende forespørsler direkte til e-postleverandøren din, laste ned kontaktene dine og deretter gjøre noe med disse dataene.

Samme med Facebook på den tiden. Hvis du ønsket å se hvilke av vennene dine som allerede var på Facebook og du ville ha kontakt med dem, ville Facebook lese inn kontaktene dine fra Gmail eller Yahoo eller Hotmail, og de ville vise deg en liste over alle kontaktene dine som allerede var på Facebook og gi deg muligheten til å få kontakt med dem.

Nå vet vi alle at dette ikke er bra, og at du ikke bør gi dine sensitive påloggingsinformasjoner til andre selskaper; det setter deg i fare. Dette var selvsagt før GDPR.

OAuth-diskusjonsgruppen ble dannet som en måte å løse problemet med delegert autorisasjon. OAuth-gruppen ga til slutt ut en spesifikasjon, og den spesifikasjonen endret til slutt måten autorisasjon fungerer på nettet. I dag er den samme Yelp-arbeidsflyten erstattet med en mye tryggere flyt. Se bildet under:

Ikke bare er denne nye flyten mye tryggere – den er også mye enklere. Når Yelp ønsker å få tilgang til Gmail-kontaktene dine, omdirigerer de deg ganske enkelt til Google (som du antagelig allerede er logget på), hvor du deretter blir møtt av samtykkeskjermen på bildet, og forteller deg hvilke spesifikke data Yelp vil ha tilgang til i din konto hvis du tillater dem det.
Yelp trenger ikke bekymre seg for å lagre dine sensitive data, og du trenger ikke bekymre deg for at Yelp misbruker legitimasjonen din.

Hva er OAuth2?

OAuth er en åpen protokoll for å tillate sikker autorisasjon på en enkel og standardisert metode fra nett-, mobil- og skrivebordsapplikasjoner.

• OAuth2 er en delegert autorisasjonsprotokoll (nevnes at den krever autentisering som første trinn).
• OAuth2 er industriens standardprotokoll for autorisasjon.
• OAuth2 er en åpen standard for tilgangsdelegering, vanligvis brukt som en måte for Internett-brukere å gi nettsteder eller applikasjoner tilgang til informasjonen deres på andre nettsteder, men uten å gi dem passordene.
• OAuth2 er en protokoll som lar en bruker gi begrenset tilgang til ressursene sine på ett nettsted, til et annet nettsted, uten å måtte avsløre legitimasjonen.

OAuth 1.0 ble opprinnelig utgitt i 2007 som en autorisasjonsmetode for Twitter API. I 2010 ga IETF OAuth Working Group ut det første utkastet til OAuth 2.0-protokollen. Som med den første OAuth, lar OAuth 2.0 brukere gi tredjeparts applikasjonstilgang til nettressurser uten å avsløre et passord. Det er imidlertid en helt ny protokoll og er ikke bakoverkompatibel med OAuth 1.0. Nye funksjoner inkluderer en ny autorisasjonskodeflyt for å tillate mobilapper, kortlivede tokens med langvarige autorisasjoner og forenklede signaturer.

Hva er OpenID Connect (OIDC)?

OAuth løste ikke alle problemene. Autorisasjon handler om å finne ut hvem som har tilgang til visse data og funksjonalitet. Autentisering handler om å logge på. OAuth løste autorisasjonsproblemene, men det gjorde ingenting med autentiseringsproblemene. Og det er derfor OIDC ble opprettet. OIDC er en nyere standard som utvider OAuth, og legger til støtte for autentisering. OIDC er en utvidelse til OAuth som gir identitet.

OAuth- og OIDC-spesifikasjonene (og utvidelsene) dekker autentisering og autorisasjon for:

• Brukere som logger på en webapplikasjon på serversiden
• Brukere som logger på en nettapplikasjon på klientsiden
• Brukere som logger på en innebygd mobilapplikasjon
• Brukere som logger på en TV/enhetsapplikasjon
• Server-til-server API-autorisasjon

Disse use case-scenariene er oversatt til et konsept som kalles grant-typer i OAuth-spesifikasjonen, og hver enkelt fungerer forskjellig og har ulike sikkerhetsprofiler som implementøren må være klar over.
I tillegg til grant-types, må implementørene også forstå tokens (spesifikt JSON Web Tokens (som er en del av OIDC-spesifikasjonen)), som legger til ytterligere læringskurver til OAuth/OIDC-implementor.

For å kunne implementere OAuth/OIDC i miljøet ditt, må du (som utvikler) fullt ut forstå:

• Hva de forskjellige OAuth-grant typene er
• Hvilke grant typer du bør bruke i søknaden i hvilke scenarier
• Hva JWT er
• Hvordan generere JWT-er sikkert og holde nøklene dine trygge
• Hvordan signere (og eventuelt kryptere) JWT-ene dine: hvilke alternativer bruker du?
• Hvordan validere JWT-er
• Hvordan vurdere sikkerhetsmessige konsekvenser av å bruke JWT-er på ulike måter

OAuth Flow OIDC Flow

PKCE – Proof Key for Code Exchange

 
Kodeflyten gjør det mulig å spesifisere en PKCE-utfordring med autentiseringsforespørsel (steg 2). Hvis utfordringen er tilstede, må en PKCE-verifikator spesifiseres med token-forespørselen (steg 3). PKCE beskytter mot autorisasjonskodeavskjæringsangrep.

Vi har snakket om OAuth og OIDC, men hva med SAML?

Du har sannsynligvis opplevd SAML-autentisering i arbeidsmiljøet. Den lar deg logge på bedriftens intranett eller idP (identity provider) og får deretter tilgang til tilleggstjenester uten å måtte legge inn legitimasjonen din på nytt. SAML er en XML-basert standard for utveksling av autentiserings- og autorisasjonsdata mellom IDP-er og tjenesteleverandører for å verifisere brukerens identitet og tillatelser, og deretter gi eller nekte tilgang til tjenester.
Bedrifter er avhengige av nettrammeverk og protokoller som OAuth2.0, OpenID og SAML for å bringe struktur og sikkerhet til forent identitet. Å vite når du skal bruke hver av dem er et viktig skritt mot å beskytte organisasjonen din fra grunnen og opp.

Konklusjon

For mobilapplikasjoner eller beskyttelse av REST API-er, er sannsynligvis OAuth eller OIDC et bedre valg. For Single Sign-On (SSO), brukstilfeller med webapplikasjoner, spiller det ingen rolle hvilken protokoll som brukes, enten OAuth/OIDC eller SAML vil gjøre jobben. Hvis du allerede kjenner SAML og du har verktøy og biblioteker som støtter SAML, er det et godt valg å fortsette med det.