OpenID er et åbent standard decentraliseret godkendelsessystem , der giver brugeren muligheden for at oprette en enkelt konto til godkendelse på en række ikke-relaterede internetressourcer ved hjælp af tredjepartstjenester [1] .
Kernefunktionen af OpenID er at levere en bærbar, klientcentreret, digital identitet til gratis og decentraliseret brug [2] .
Standarden beskriver kommunikationsprocessen mellem internetressourcer (Relying Parties), der kræver godkendelse, og OpenID-udbydere (OpenID-udbydere). Der er flere OpenID-udbydere, der hoster OpenID- URL'er [3] . OpenID-godkendelse bruges af Google , Yahoo! , AOL , LiveJournal , MySpace , IBM [4] , Steam [5] og Orange . En udvidelse til standarden (OpenID Attribute Exchange) letter overførslen af brugerdata, såsom navn eller køn, fra en OpenID-udbyder til en internetressource [6] .
I december 2009 var der over 1 milliard OpenID-konti og omkring 9 millioner websteder, der understøttede OpenID-teknologi [7] .
Den nuværende version af standarden, OpenID Connect 1.0, blev udgivet i februar 2014 og blev opdateret i november 2014 [8] [9] .
I 2005 foreslog Brad Fitzpatrick , kendt som skaberen af LiveJournal , som på det tidspunkt arbejdede hos Six Apart , konceptet med en enkelt konto for forskellige internetressourcer til internetsamfundet [10] . Han foreslog at holde sin konto på én server og bruge denne konto, når han registrerede sig på andre internetressourcer. Oprindeligt kaldt Yadis (et akronym for "Yet another distributed identity system"), protokollen fik sit navn OpenID efter Six Apart registrerede openid.net domænenavnet til sit projekt. Snart blev understøttelse af OpenID implementeret på LiveJournal, og denne teknologi tiltrak hurtigt internetsamfundets opmærksomhed [11] .
I 2006 blev den første OpenID-specifikation oprettet - OpenID Authentication 1.1 [12] .
Den 5. december 2007 udgav Sun Microsystems , VeriSign og en række virksomheder involveret i udviklingen af OpenID OpenID 2.0-specifikationen og erklærede officielt, at de ikke ville fremsætte krav, hvis nogen bruger OpenID-teknologien, medmindre handlingerne fra den person, der bruger teknologien er rettet mod implementering af teknologi eller ejerskab af teknologi [13] .
OpenID-varemærket blev registreret i USA i marts 2008 [14] .
På et websted er der for eksempel example.comen login-formular med et enkelt indtastningsfelt til en OpenID identifikator. Ofte er OpenID-logoet ved siden af dette felt. For at autorisere på dette websted ved hjælp af din identifikator, for eksempel pupkin.openid-provider.orgregistreret hos OpenID-udbyderen openid-provider.org, skal brugeren indtaste sin identifikator i login-formularen, der tilbydes på siden. Siden example.com omdirigerer derefter brugeren til udbyderens websted. Udbyderens websted beder brugeren om at bekræfte, om brugeren virkelig ønsker at give oplysninger om sin konto. Hvis brugeren accepterer, omdirigerer udbyderens websted brugeren tilbage til den afhængige parts websted. Ved en omvendt omdirigering vil udbyderen videregive brugeroplysningerne til den stolende part [15] .
En OpenID-udbyder er for eksempel LiveJournal , så du kan bruge adressen på din dagbog i LiveJournal som en OpenID-identifikator [16] .
OpenID giver en bruger mulighed for at bruge én konto, der er registreret hos en OpenID-udbyder på flere andre websteder. Brugeren kan vælge, hvilke oplysninger der skal gives til webstedet. Udveksling af profiloplysninger eller andre oplysninger, der ikke er beskrevet i OpenID-specifikationen, kan implementeres over OpenID-protokollen ved hjælp af supplerende tjenester. For at gøre dette er protokoludvidelsesmekanismen, der officielt understøttes af OpenID-protokollen [17] .
Der er mulighed for at uddelegere OpenID. Det betyder, at ejeren af et bestemt domænenavn kan bruge det som et synonym (alias) til en allerede eksisterende OpenID identifikator, der er hentet fra enhver OpenID-udbyder. For at gøre dette skal du tilføje et par metatags til den side, der bruges som delegeret [18] .
OpenID-systemet er et decentralt system. Det betyder, at der ikke er nogen central tjeneste eller organisation, der tillader brugen af systemet eller registrerer internetressourcer eller OpenID-udbydere, der kræver OpenID-godkendelse. Slutbrugeren kan frit vælge, hvilken OpenID-udbyder, der skal bruges, og beholde identifikatoren, hvis OpenID-udbyderen skifter [1] .
Standarden kræver ikke JavaScript eller moderne browsere , men godkendelsesskemaet er godt kompatibelt med AJAX- tilgangen . Det betyder, at slutbrugeren kan autentificere til webstedet uden at forlade den aktuelle side. I dette tilfælde vil kommunikationen af internetressourcen med OpenID-udbyderen foregå i baggrunden. OpenID-godkendelse bruger kun standard HTTP (S) -anmodninger og -svar, så standarden kræver ikke, at brugeren installerer yderligere software . OpenID kræver ikke brug af cookies eller andre sessionsstyringsmekanismer. Forskellige udvidelser kan gøre det lettere at bruge OpenID, men er ikke påkrævet for at bruge standarden [2] .
OpenID Foundation (OIDF) er en non-profit organisation, der blev dannet i juni 2007 for at administrere ophavsret, varemærker, markedsføring og andre aktiviteter relateret til OpenID-fællesskabet [20] .
Organisationens bestyrelse består af 4 medlemmer af samfundet og 8 virksomhedsmedlemmer [21] :
| Fællesskabets medlemmer
• John Bradley ( Independent ) (eng. John Bradley) • George Fletcher (AOL) (engelsk George Fletcher) • Mike Jones ( Microsoft ) (eng. Mike Jones) • Nat Sakimura ( Nomura Research Institute ) |
Virksomhedsmedlemmer
• Google - Adam Dawes • Microsoft - Anthony Nadalin (eng. Anthony Nadalin) • Ping-identitet - Pamela Dingle (eng. Pamela Dingle) • Symantec - Brian Berliner • Verizon - Bjørn Helm (eng. Bjorn Hjelm) • Oracle - Prateek Mishra • VMware - Ashish Jain • US Department of Health and Human Services - Debbie Bucci |
I USA registrerede OpenID Foundation i marts 2008 OpenID-varemærket. Det var tidligere ejet af NetMesh Inc. I Europa blev OpenID-varemærket den 31. august 2007 registreret af OpenID Europe Foundation [14] .
OpenID-godkendelse giver slutbrugeren en måde at bevise sin identitet på siden uden at indtaste sin adgangskode, e-mail eller andre oplysninger, som han ikke ønsker at indtaste på denne ressource. OpenID 1.1-specifikationen giver ikke nogen mekanisme til udveksling af slutbrugerprofiloplysninger [18] .
Den største forskel mellem OpenID 2.0 og OpenID 1.1 for slutbrugeren er evnen til at bruge XRI som en identifikator. OpenID 2.0, i modsætning til OpenID 1.1, understøtter HMAC-SHA256-algoritmen - en 256-bit ( [RFC2104 ] digital signatur, som gør godkendelse af OpenID-meddelelser mere sikker. OpenID 2.0 introducerede en udvidelsesmekanisme, der giver dig mulighed for at tilføje yderligere oplysninger til autentificeringsanmodninger og svar [22] .
OpenID 2.0 er kompatibel med OpenID 1.1 [23] .
Tredje generation af OpenID-teknologi, som er en autentificeringstilføjelse over OAuth 2.0 - autorisationsprotokollen . OpenID Connect giver internetressourcer mulighed for at verificere en brugers identitet baseret på godkendelse udført af en godkendelsesserver. Til arbejde bruges RESTful API beskrevet i specifikationen. OpenID Connect definerer også yderligere mekanismer til stærk kryptering og digital signatur. Standarden giver mulighed for yderligere funktioner såsom sessionsstyring og opdagelse af OpenID-udbydere [8] .
Mens integration af OAuth 1.0a-standarden med OpenID 2.0 kræver en udvidelse, integrerer OpenID Connect allerede OAuth 2.0-funktioner med selve protokollen [24] .
Nogle forskere mener, at OpenID-protokollen er sårbar over for phishing-angreb , når angribere i stedet for en udbyder dirigerer slutbrugeren til et websted med et lignende design. Hvis brugeren ikke bemærker substitutionen, indtaster han sine autentificeringsdata (login, adgangskode). Som et resultat kan angribere præsentere sig selv for internetressourcer som en given bruger og få adgang til hans informationer, der er lagret på disse ressourcer [25] .
Phishing-angreb er også mulige, når et websted, der understøtter OpenID-autorisation, forfalskes for at få oplysninger om brugeren fra udbyderen. Ved at bruge "stealth redirect"-sårbarheden kan angribere skabe den illusion for brugeren, at oplysningerne er anmodet om af det rigtige websted [26] .
OpenID indeholder ikke mekanismer til at forhindre phishing-angreb. Ansvaret for phishing-angreb flyttes til OpenID-udbydere [27] .
For at beskytte mod phishing kan brugere bruge ekstra software såsom Microsofts Identity Selector [28] . Der er også løsninger, der ikke kræver installation af yderligere software, såsom BeamAuth, der bruger browserbogmærker til sit arbejde [29] .
Hvis TLS/SSL -protokoller ikke bruges til at sikre forbindelsen mellem brugeren og OpenID-udbyderen , så opstår der en sårbarhed i sidste fase af godkendelsen. For at omdirigere brugeren fra sig selv til internettjenesten sender udbyderen brugeren en speciel URL. Problemet er, at enhver, der kan få denne URL (for eksempel ved at sniffe et parsnoet kabel), kan afspille den igen og få adgang til siden som bruger. Nogle udbydere bruger en engangskode ( Nonce ) til at beskytte mod dette angreb, hvilket giver dig mulighed for kun at bruge en given URL én gang. Ikke-løsningen virker kun, hvis brugeren bruger URL'en først. En angriber, der lytter på kommunikationskanalen og er mellem brugeren og internetudbyderen , kan dog få URL'en og øjeblikkeligt afslutte brugerens TCP-forbindelse og derefter udføre angrebet. Engangskoder beskytter således kun mod passive angribere, men kan ikke forhindre angreb fra en aktiv angriber. Brugen af TLS/SSL i godkendelsesprocessen eliminerer denne risiko [30] .
Brugeren kan ændre OpenID-udbyderen og dermed frigive sin identifikator fra den tidligere udbyder. Den nye bruger kan overtage dette ID og bruge det på de samme websteder som den tidligere bruger. Dette vil give den nye bruger adgang til alle oplysninger forbundet med det pågældende ID. Denne situation kan opstå ved et uheld - det er ikke nødvendigt, at den nye bruger er en hacker og ønsker at få adgang til de specificerede oplysninger [31] .
I OpenID 2.0-specifikationen, for at løse problemet med at genbruge en identifikator, anbefales det at bruge fragmenter - et fragment unikt for hver bruger skal tilføjes til identifikatoren [19] .
I 2012 offentliggjorde forskere et papir, der beskrev to sårbarheder i OpenID. Begge sårbarheder giver en angriber mulighed for at få adgang til ofrets konto [32] .
Den første sårbarhed bruger OpenID Attribute Exchange. Problemet er, at nogle internettjenester ikke validerer de data, der sendes gennem Attribute Exchange. Hvis Attribute Exchange bruges til at videregive manipulationssikre oplysninger om en bruger (såsom køn), så kan denne sårbarhed ikke udnyttes. Attribute Exchange kan dog også bruges til at overføre for eksempel brugerens e-mail. Angriberen forsøger at autentificere til den afhængige parts websted og tilføjer offerets e-mail-udbyder i svaret. Hvis den stolende part ikke bekræfter ægtheden af disse oplysninger, vil angriberen blive identificeret som et offer. På denne måde kan du få adgang til enhver registreret konto. Ifølge forskernes rapport blev mange populære websteder berørt af dette angreb, herunder Yahoo! Mail [33] .
Den anden sårbarhed er relateret til en fejl på udbyderens side og giver også adgang til en konto på den afhængige parts hjemmeside. Udbyderens svar indeholder feltet openid.ext1.value.email , som af den stolende part behandles som brugerens e-mail. Den type data, der tilføjes til dette felt af udbyderen, kan dog styres af en angriber - anmodningen til udbyderen indeholder feltet type.email med et link til skemaet, der beskriver dette felt. En angriber kan tilføje et link til et skema, der beskriver brugernavnet i type.email . Hvis en angriber kan registrere sig på udbyderens websted med et navn, f.eks. [email protected], vil udbyderen tilføje dette navn til feltet openid.ext1.value.email , og den stolende part vil antage, at kontoen med denne e-mail tilhører angriberen. Google- og Paypal- implementeringer er blevet identificeret som sårbare [33] .
OpenID har offentliggjort rapporter om begge sårbarheder, og opdateringer er blevet frigivet for at rette dem [34] [35] .
| Autentificering og nøgleudvekslingsprotokoller | |
|---|---|
| Med symmetriske algoritmer | |
| Med symmetriske og asymmetriske algoritmer | |
| Protokoller og tjenester, der bruges på internettet | |