Programmering

GNAP: OAuth den næste generation

Året var 2012, og en revideret sikkerhedsprotokol kaldet OAuth 2 fejede internettet, så brugerne kunne bruge sikkerhedsudbydere til let at logge på websteder. Mange enkeltloginsystemer, fra AWS's Cognito til Okta, implementerer OAuth. OAuth er det, der giver dig mulighed for at "godkende med Google" eller andre udbydere til et helt andet websted eller en anden applikation.

Det fungerer som en ølfestival. Du går til et skrivebord og godkender med dit id (og nogle penge), og de giver dig tokens. Derfra går du til hvert øltelt og bytter et symbol til en øl. Den enkelte brygger behøver ikke kontrollere dit ID eller spørge, om du har betalt. De tager bare symbolet og giver dig en øl. OAuth fungerer på samme måde, men med websteder i stedet for øl.

Desværre er OAuth den bedste ølfestival 2020 at tilbyde.

Jeg talte med Dan Moore fra FusionAuth om OAuth og en foreslået erstatning kaldet GNAP - som sandsynligvis udtalt uden G som "lur." Udtalen fremmer ideen om, at sikkerhed er et rigtig spændende felt. GNAP adresserer nogle begrænsninger af OAuth og krydrer det med nye funktioner.

Hvorfor udskifte, eller rettere udvide, OAuth? OAuth blev designet omkring browsere. Det antages, at ophavsmanden, der fremsætter anmodningen, kan håndtere en HTTP-omdirigering. Dette webbrowserfokus er en anstødssten for mobilapps eller enhver form for "ting" på "Tingenes internet". Derudover er OAuth-parter ligesom det 2007 og kræver, at du sender formularparametre i stedet for JSON.

OAuth-specifikationen var vag nogle steder, og verden har ændret sig siden 2012. Der er en masse RFC'er og BCP'er, i det væsentlige tilføjelsesspecifikationer, som du skal implementere for flere muligheder, bedre sikkerhed og generel kompatibilitet. En separat indsats kaldet OAuth 2.1 håber at kollapse nogle af disse tilføjelser til en mere sammenhængende enkelt spec. For nogle af motivationerne til OAuth 2.1, se Lee McGovern fra Oktas indlæg "Hvor mange RFC'er skal der til for at skifte en pære." OAuth 2.1, i modsætning til GNAP, er bare en trinvis frigivelse uden nye væsentlige ændringer udover at kombinere stakken af ​​specifikationer i en enkelt specifikation.

GNAP-specifikationen er stadig i sine tidlige faser. GNAPs forfattere planlægger at gå længere end OAuth 2.1 og ændre selve protokollens natur. I stedet for at bruge HTTP-parametre kan du bruge JSON. Applikationens slutpunkter kan findes. Du behøver ikke at understøtte omdirigeringer (eller de forskellige hacks omkring det). Moore henviser til disse ændringer under det dejlige udtryk "udviklerergonomi".

Et centralt mål for GNAP er adskillelsen af, hvem der anmoder om ressourcerne (RQ), og hvem der ejer ressourcerne (RO).

IETF

GNAP foreslår også at understøtte nye sikkerhedsfunktioner såsom:

  • Asynkron og URL til applikationsstart. Dette er forskellige godkendelsesstier, der gør det muligt for klienten at godkende uden en omdirigering. GNAP gør det også muligt for applikationer at godkende til tredjepartsressourcer, som ressourceserveren og autorisationsserveren ikke har direkte adgang til.
  • Anmod om fortsættelse. Disse giver klienter mulighed for at forhandle om ting som omdirigeringer eller andre godkendelsesoplysninger under godkendelsesprocessen. De tillader også en klient at forhandle om yderligere privilegier eller adgangstokener.
  • Flere adgangstokens. Disse giver klienter mulighed for at godkende for mange ressourcer på én gang, for eksempel som både bruger og administrator.
  • Afsenderbegrænsningstokens. Mens der er tilføjelser til OAuth 2 til denne funktion kaldet DPOP og MTLS, ville GNAP bygge dette direkte ind i protokollen. Vend tilbage til vores eksempel på øltelt. Hvad hvis vi også skulle hviske en adgangskode i sælgerens øre, mens vi afleverede tokenet? Hvis vores token blev droppet (eller opfanget), ville det ikke have noget at gøre, fordi bæreren ikke ville have adgangskoden.
  • Og GNAP får Kerberos spøgelse til at skrige.

Lyder godt? Kan du begynde at bruge GNAP i dag? Hvis du er interesseret i at samarbejde, kan du forkaste en af ​​de prototyper, der gik ind i det eksisterende forslag på GitHub.

Ifølge Moore sigter forfatterne mod at frigive GNAP i 2022. Da hver dag i 2020 er som en uge i et typisk år, er GNAP langt væk. GNAP-arbejdsgruppen leder dog efter samarbejdspartnere, og du kan tilmelde dig mail-listen og tilbyde din feedback og ekspertise. Jeg antager, at du ikke kan ordne alt i verden, men du kan i det mindste hjælpe med at ordne OAuth.