OpenID er en desentralisert digital identifiseringsstandard , med hvilken en bruker kan identifiseres på en nettside gjennom en URL (eller en XRI i gjeldende versjon) og kan verifiseres av enhver server som støtter protokollen.
På nettsteder som støtter OpenID, trenger ikke brukere å opprette en ny brukerkonto for å få tilgang. I stedet trenger de bare å ha en identifikator opprettet på en server som verifiserer OpenID, kalt en identitetsleverandør, eller IdP .
Identitetsleverandøren kan bekrefte brukerens OpenID-identifikasjon til et nettsted som støtter dette systemet.
I motsetning til andre Single Sign-On- arkitekturer spesifiserer ikke OpenId autentiseringsmekanismen. Derfor avhenger sikkerheten til en OpenID-tilkobling av tilliten som OpenID-klienten har til identitetsleverandøren. Hvis det ikke er tillit til leverandøren, vil autentiseringen ikke være egnet for banktjenester eller elektroniske handelstransaksjoner, men identitetsleverandøren kan bruke sterk autentisering og den kan brukes til disse formålene.
OpenID vinner frem på grunn av kunngjøringen fra noen store nettsteder som Technorati om å ta i bruk dette systemet. [ 1 ] MediaWiki - programvaren har en utvidelse for å tillate OpenID-tilgang, [ 2 ] men den brukes for øyeblikket ikke på Wikipedia-serverne.
OpenID-systemet ble opprinnelig utviklet av LiveJournals Brad Fitzpatrick, selv om VeriSigns David Recordon, JanRains Josh Hoyt og Sxips Dick Hardt nå er medforfattere. Fremtidige OpenID-spesifikasjoner vil bli utviklet på et e- postlistebasert meritokrati . For å støtte implementeringen av OpenID kunngjorde en gruppe selskaper i august 2006 et utviklingsbidragsprogram som tilbyr $5000 til de ti første gratis programvareprosjektene som implementerer full OpenID-kompatibilitet.
Fra og med versjon 1.1 bruker OpenID Yadis tjenesteoppslagsprotokoll . I desember 2007 ble versjon 2.0 av OpenID Authentication utgitt [ 3 ] ).
En grunnleggende ordliste over termer brukt med OpenID:
Endelig bruker personen som ønsker å få tilgang til et nettsted med sin identitet. identifikator URL eller XRI valgt av sluttbrukeren som deres OpenID identifikator. identitetsleverandør En tjenesteleverandør som tilbyr OpenID XRI eller URL -registrering og gir OpenID-autentisering. selvsikker del nettstedet som ønsker å bekrefte identiteten til sluttbrukeren.Et nettsted, for eksempel example.com, som ønsker å tilby tilgang til sine besøkende gjennom OpenID, installerer et identifikasjonsskjema på noen av sidene sine. I motsetning til de typiske identifikasjonsskjemaene som ber brukeren om navn og passord, er det i dette tilfellet kun ett felt for OpenID-identifikatoren. Nettstedet kan velge å vise en liten OpenID-logo ved siden av feltet. Dette skjemaet vil bli koblet til en implementering av OpenID-klientbiblioteket.
Hvis for eksempel Alice ønsker å logge på example.commed OpenID-identifikatoren alicia.proveedor-openid.orgsom hun tidligere har registrert hos identitetsleverandøren proveedor-openid.org, går hun ganske enkelt til example.comog skriver alicia.proveedor-openid.orginn påloggingsboksen for OpenID. Fra og med OpenID-autentiseringsversjon 2.0 (og i noen av OpenID 1.1-implementeringene) kan Alice også identifisere seg ved å skrive inn et i-navn som =example.aliciaeller =example.comunidad*alicia.
Hvis identifikatoren er en URL, er det første ( example.com)-delen må gjøre å transformere den til en kanonisk form, av typen http://web.archive.org/web/http://alicia.proveedor-openid.org/. Med OpenID 1.0 ber den pålitelige parten deretter om nettsiden på den URL-en og oppdager via en HTML-lenkekode at leverandørens server antagelig er http://proveedor-openid.org/openid-auth.php. Den finner også ut om du bør bruke en delegert identitet eller ikke (se nedenfor). Fra og med OpenID 1.1, utfører klienten oppdagelse av disse dataene ved å be om ' XRDS-dokumentet (også kalt Yadis-dokumentet ) med innholdstype application/xrds+xml, som kan være tilgjengelig på den URL-en og alltid vil være tilgjengelig via en XRI.
Det er to måter den tillitsfulle parten kan kommunisere med identitetsleverandøren på:
Det andre alternativet er mer populært på nettet; det kan også skje at en checkid_immediateender opp med å bli en checkid_setuphvis operasjonen ikke kan automatiseres.
Først etablerer den tillitende parten og leverandøren (valgfritt) en delt hemmelighet, som lagres av den stolende parten. Hvis brukt checkid_setup, omdirigerer den pålitelige parten brukerens nettleser til leverandøren. I eksemplet vil Alices nettleser bli omdirigert til proveedor-openid.orgslik at Alice kan autentisere seg mot leverandøren.
Autentiseringsmetoden kan variere, men vanligvis ber en OpenID-leverandør om et passord (og lagrer deretter muligens brukerens økt ved hjelp av informasjonskapsler , slik mange passordbaserte autentiseringssider gjør). Hvis Alicia ikke har en aktiv økt i proveedor-openid.org, vil den be om passordet hennes. Når du har økten åpen, vil serveren spørre deg om tilliten den tilbyr deg http://example.com/openid-retorno.php(siden utpekt av example.comsom destinasjonen som brukeren skal returnere til etter å ha fullført autentiseringen for å motta identitetsdetaljer). Hvis hun svarer positivt, anses OpenID-autentiseringen som vellykket, og nettleseren blir omdirigert til den angitte retursiden med den oppgitte legitimasjonen. Hvis Alice bestemmer seg for å ikke stole på den tillitsfulle partens nettsted, vil nettleseren også bli omdirigert, men den stolende parten vil bli varslet om avvisningen, og dermed nekte example.comå autentisere Alice i retur.
Prosessen er imidlertid ikke fullført ennå fordi du på dette stadiet example.comikke kan bestemme om den mottatte legitimasjonen faktisk ble mottatt fra proveedor-openid.org. Hvis de tidligere har etablert en delt hemmelighet, kan forbrukeren validere den mottatte delte hemmeligheten med tidligere lagret legitimasjon. Hver forbruker kalles stateful fordi den har den delte hemmeligheten mellom øktene. Til sammenligning må en statsløs eller stum forbruker foreta et nytt spørsmål ( check_authentication) for å sikre at dataene faktisk kom fra proveedor-openid.org.
Etter at Alicias identifikator er bekreftet, vil hun bli ansett som registrert example.comsom alicia.proveedor-openid.org. Siden kan da lagre økten eller, hvis dette er hennes første registrering, be Alice om å angi spesifikk informasjon example.comfor å fullføre registreringen.
OpenID Foundation (i USA), samt dets datterselskap OpenID Europe , [ 4 ] ble opprettet i 2007. Det er en ideell organisasjon hvis rolle er organiseringen og utviklingen av OpenID-rammeverket for fellesskapet, samt as Administrer din immaterielle eiendom.
Fra og med versjon 2.0 av OpenID-autentisering (og i noen av OpenID 1.1-implementeringene), er det to typer identifikatorer: URL-er og XRI-er.
Det er to måter å få en gyldig OpenId URL som kan brukes til å logge på alle nettsteder som støtter OpenID.
(Hovedartikkel: XRI )
XRI- er er et nytt identifikasjonssystem på Internett , designet spesielt for digitale identiteter på tvers av domener. XRI er av to former i-navn og i-nummer som vanligvis registreres samtidig som ekvivalenter. I-navn kan omdisponeres (i likhet med domenenavn), mens i-numre aldri omtilordnes. Når et XRI i-navn brukes som en OpenID-identifikator, blir det umiddelbart løst til det tilsvarende i-nummeret (CanonicalID-elementet i et XRDS -dokument ). Dette i-nummeret er OpenID-identifikatoren som er lagret av den pålitelige parten. På denne måten er brukeren og den pålitelige parten beskyttet mot identitetsendringer som kan skje med en URL basert på et DNS-navn som kan tilordnes på nytt.
OpenID har mottatt en rekke grunnleggende kritikk, knyttet til problemer fra ulike felt, men spesielt sikkerhet og personvern. Samlingen av alle identiteter innebærer høy risiko, sammen med det faktum at identitetsserveren vil kjenne til alle nettsidene som besøkes hver dag. Videre, hvis sikkerheten til brukerens datamaskin eller server ble kompromittert, ville hele brukerens digitale liv stå ubeskyttet. [ 5 ]