OAuth er en godkjennings- og autorisasjonsprotokoll, opprinnelig utviklet for webapplikasjoner, født i Twitter i 2006.

Det gjør det mulig for tredjepartsprogramvare å gjøre noe på vegne av deg, for en begrenset tid og uten at den programvaren gir full, permanent tilgang til reservert informasjon. Den vanligste analogien er valetnøkler.

La oss dykke litt dypere og finne ut mer om OAuth.

Spørsmål: Så, betjentnøkler. Du mener de nøklene som normalt leveres til parkeringskasser på hoteller?

A: Ja. Disse nøklene gjør det mulig å åpne, starte og kjøre bilen, men bare for en veldig kort tur og uten å åpne kofferten. OAuth fungerer som en valetnøkkel for dine data. Det gir midlertidig og begrenset tilgang til noe som er ditt, uten å gi full kontroll.

Q: Nå forstår jeg hva du mener, men ... er dette et ekte verdensproblem?

A: Det ble en når nettbaserte tjenester og sosiale nettverk i alle sine former, fra Twitter og Flickr til fjernbank, ble ikke bare allestedsnærværende, men sammenkoblet - de er mye mer nyttige når du kan få dem til å jobbe sammen.

Spørsmål: Du henviser til saker som for eksempel publisering av et Flickr-galleri på Facebook.

A: Ja, nøyaktig. Å være i stand til å gjøre det uten å skrive inn alt manuelt, er flott. Men å gjøre det uten noe som OAuth kan bety at disse nettstedene gir full tilgang til alle dine ting (for eksempel filer, kontaktlister eller full tilgang til tjenester).

Spørsmål: Så derfor snakket du om både autentisering og autorisasjon?

A: Korrekt. Godkjenning betyr å ha en måte å bevise at du virkelig er deg. Vær oppmerksom på at det generelt ikke spiller noen rolle om du er et menneske eller et program. Mens autorisasjon er en separat, like nødvendig tjeneste. Hvis en person eller et program har allerede bevist Facebook som de er, betyr det ikke at de har tillatelse til å oppdatere vår status som om de var oss.

Spørsmål: Kunne ikke OpenID har blitt brukt til dette?

A: OpenID omhandler kun godkjenning. OAuth hjelper i stedet i alle tilfeller hvor (med OAuth-terminologi) noen programvare (klient) som ønsker å få tilgang til data på vegne av den som har rett til å godkjenne slik tilgang (ressurseier), er helt skilt fra og ukjent til , programvaren eller tjenesten som faktisk lagrer disse ressursene.

Spørsmål: Vent et sekund! Noe som dette var mulig år før OAuth!

Svar: Ja, men i de fleste tilfeller mente det å bruke bare en konto av et nettverk av allerede samarbeidende nettsteder, eller gi minst én av dem dine brukernavn og passord på alle de andre. OAuth forsøker å lukke dette sikkerhetshullet.

Spørsmål: Du mener at du gir tilgang til det som er inne i en webkonto uten å gi ut passordet og brukernavnet mitt?

Svar: La oss anta at du har kommentert noen blogg, og vil at bloggen skal legge den på Twitter på dine vegne, for å lagre skrive. Når du forteller bloggens programvare for å gjøre dette (for eksempel ved å klikke på en knapp), vil den sende en forespørsel til Twitter, som inkluderer en identifikasjonskode og listen over data eller tjenester som den vil ha tilgang til på dine vegne. Twitter (ikke bloggen!) Vil presentere deg et egendefinert web-skjema for godkjenning på serveren. Hvis du logger inn med hell på Twitter og svarer "ja" til den forespørselen, har du autorisert Twitter for å tilfredsstille forespørselen fra bloggen. Uten å overgi passord og brukernavn.

Q: Cool! Hva så?

Sv: Twitter vil fortelle nettleseren din om å gå tilbake til bloggen, men med en spesiell nettadresse som inneholder en "tilgangstoken" eller en enkelt godkjenningsnøkkel. På det tidspunktet vil bloggprogramvaren kunne presentere tokenet til Twitter, som bevis på at det er den som bare fikk din tillatelse til å gjøre noe med eller med kontoen din.

Spørsmål: Og dette vil fungere med alle OAuth-kompatible nettsider, ikke bare Twitter?

A: Det er riktig. Så lenge disse nettstedene ikke avviser den første forespørselen, selvfølgelig. Foruten bekvemmelighet for sluttbrukeren var en annen kraftig driver for OAuth ønsket om å gjøre livet vanskeligere for spambots og andre ondsinnede applikasjoner.

Spørsmål: Hvordan ville OAuth gjøre det?

A: Uansett brukerautorisasjon kan et program fungere som beskrevet bare hvis det har tillatelse til å gjøre det fra nettsiden den ønsker å få tilgang til. OAuth oppnår dette ved å bruke flere identifikasjonstaster eller legitimasjonsbeskrivelser, parallelt.

Spørsmål: Hva er disse legitimasjonene og hvem som utsteder dem?

A: Den som vi allerede har nevnt, som brukes til å erklære at tilgang fra noe program er tillatt uten å gi passordet til det, kalles token-legitimasjonsbeskrivelser. Før du kommer til det punktet, må kunden imidlertid ha sendt til kunden sin gyldige klientlegitimasjon.

Generelt utstedes de av webserveren selv. Når utviklerne av noe programvare vil legge til OAuth-evner til det, registrerer de seg hos serveren for å få slike legitimasjonsbeskrivelser eller nøkler. Dette gjør det litt lettere å stoppe noen skadelig programvare, men også brøt mange eksisterende programmer.

Spørsmål: Du fortsetter å snakke om nettsteder. Betyr dette at OAuth er ubrukelig av stasjonær programvare?

A: Nå er det et triksespørsmål. Teknisk sett er det ingenting i OAuth som hindrer klienter i å være tradisjonelle stasjonære applikasjoner som kjører inne i datamaskinen. I praksis gjør det (minst med OAuth 1.0) heller livet vanskeligere for utviklere av god tro, eller hele klientens legitimasjonskonsept er nesten ubrukelig. Spesielt når du bruker open source-programvare.

Spørsmål: Argh! Nå er det ille, men hvorfor?

Svar: Fordi ordningen jeg beskrev, fungerer perfekt når klientlegitimasjonen er innebygd i kildekode og / eller kompilerte programmer som bare kjører inne i en hvilken som helst webserver, hvor ingen kan lese legitimasjonsbeskrivelsene i kildekoden eller ved hjelp av hex redaktører og lignende verktøy, i kjørbare filer.

Spørsmål: Er dette hvorfor problemet er enda større med åpen kildekode-programvare?

A: Akkurat. Hvis du setter noe som skal forbli privat i noen kildekoden at alle har rett til å laste ned og studere ... det er ikke privat pr. Definisjon, er det?

Q: Visst, men dette gjør bare ordningen mindre nyttig. Hvorfor sa du også at OAuth bryter eksisterende programvare?

A: Fordi før OAuth 1.0, kan noen med grunnleggende kunnskap om shell scripting og cUrl (inkludert din virkelig!) På bare noen få minutter pakke inn et skript som automatisk vil logge på Twitter, lese en tidslinje eller legge inn en kvitring. OAuth gjorde dette umulig uten gyldige, registrerte kundeopplysninger. Selv når du får disse legitimasjonene, tar det mye lenger tid enn å skrive manuset i utgangspunktet!

Spørsmål: Er det ikke noen måte å lappes på disse skriptene?

A: Selvfølgelig er det: bruk bare ett av de mange programvarebiblioteker som allerede er registrert. Dette gjør imidlertid disse skriptene mye mer kompliserte å skrive og vedlikeholde enn de pleide å være. Inntil OAuth 2.0 er utgitt, minst.

Q: Du mener at det er en versjon 2.0 som kommer? Når?

A: Prognosen, mens vi skriver, er at OAuth 2.0 skal være ferdig innen utgangen av 2011.

Spørsmål: Hva er nytt i OAuth 2.0? Vil det løse disse problemene?

A: Det kunne. En av de viktigste endringene er tillegg eller omdefinering av flere såkalte "strømmer" for å få legitimasjon på den mest enkle måten, selv i scenarier der klienter ikke er webservere, men for eksempel programvare som kjører på mobile enheter. Det er også en informasjonskapselbasert flyt som skal gjøre det mulig å gjenopplive de gamle CURL-baserte webautomatiseringsskriptene. Det bør også være flere ytelsesoptimeringer, fordi OAuth 1.0 ikke skaleres veldig bra.

Spørsmål: Hvor kan jeg finne ut mer?

Den offisielle OAuth-introduksjonen.