Is een ‘social identity’ te vertrouwen?

Voor sociale netwerken, Facebook, Google+, is het interessant om als identityprovider op te treden, zegt Rob van der Staaij, want daarmee binden zij hun gebruikers. Maar voor organisaties kleven daar bezwaren aan. De identiteiten van mensen die zich registreren bij zo’n netwerk, worden in de meeste gevallen niet geverifieerd. Van der Staaij onderzoekt de verificatiemogelijkheden.

Social networks als Facebook en Google+ worden steeds vaker aangewend als identityprovider, de partij die borg staat voor de authenticiteit van een identiteit (meestal een gebruiker) en op grond daarvan een assertion of token (zie kader) afgeeft. De uitnodiging ‘Meld je aan met je Facebook-account’ is tegenwoordig een bekend fenomeen op websites. Voor gebruikers is het aanmelden met een social account aantrekkelijk, omdat dan geen gebruikersnaam en wachtwoord hoeft te worden aangemaakt en men de regie houdt over de eigen identiteit, een concept dat ook wel bekend staat als bring your own identity (BYOI). In de mobiele ­wereld is dit zonder meer van waarde. ­Gebruikers moeten zich bij dat alles wel bewust zijn dat hun gegevens worden gedeeld met een website of app van een derde partij.

Organisaties daarentegen moeten voor zichzelf nagaan of zogenoemde social identities aanvaardbaar zijn. Social networks hebben geen bijzondere relatie met de meeste organisaties en hebben heel andere belangen dan het beschermen van vertrouwelijke informatie van onbekende partijen. Voor social ­networks is het alleszins interessant om als identityprovider op te treden, want hiermee binden zij de gebruiker nog meer aan zich, vooral op de langere termijn. Als gevolg hiervan stroomt meer informatie binnen, wat weer tot gevolg heeft dat meer potentiële ­bezoekers naar de site worden getrokken en er meer kan worden verdiend aan reclame en andere services.

Uit diverse onderzoeken blijkt dat inmiddels ongeveer dertig procent van de organisaties social identities accepteert. Nog eens tien procent overweegt het, maar zestig procent van de organisaties is voorlopig niet van plan om social identities toe te laten tot hun diensten. Kijken we naar de gebruikersgroepen van wie de social identities worden geaccepteerd, dan zien we dat het bij het merendeel om klanten gaat. In iets mindere mate betreft het partners. De social identities van medewerkers worden het minst als zodanig geaccepteerd.

Het bezwaar van social identities ligt voor de hand: de identiteiten van de mensen die zich registreren bij een social network worden in verreweg de meeste gevallen niet geverifieerd. Dit gegeven wordt dan ook als voornaamste reden aangevoerd door organisaties die huiverig zijn voor het toelaten van social identities, ondanks het gemak dat ­ervan uitgaat.

 

Verificatie

De mogelijkheden die organisaties ter beschikking staan om social identities te verifiëren liggen niet voor het oprapen. Ze zijn ­ofwel omslachtig ofwel weinig toegankelijk. Maar voordat die mogelijkheden worden verkend, moeten organisaties zich altijd afvragen of het wel nodig is om social identities te verifiëren. Het kan zijn dat een succesvolle transactie belangrijker is dan zekerheid over de identiteit met wie de transactie is afgesloten, zeker als het gaat om transacties met een laag risicoprofiel. Een afweging is hier dus noodzakelijk. Is verificatie wel nodig, dan bestaat de grote uitdaging uit het linken van de social identity aan een fysieke identiteit, een activiteit die bekend staat als identity proofing. Dit kan door aanvullende bronnen te raadplegen, zoals onlinetelefoongidsen, commerciële bronnen en overheidsregistraties. Al deze bronnen hebben hun beperkingen. Ze zijn onvolledig, alleen toegankelijk voor geautoriseerd personeel of onderhevig aan strikte regelgeving zoals de privacywetgeving. Er zijn ook leveranciers die producten leveren om identiteiten van social networks te analyseren. Hieraan hangt uiteraard een prijskaartje. Dergelijke analyses geven weliswaar geen absoluut uitsluitsel over ­iemands identiteit, maar er kan wel met ­redelijke zekerheid worden gezegd of er wel of geen sprake is van een fictieve identiteit. Net zo omslachtig, maar wel betrouwbaar is de gebruiker zelf vragen om aanvullende informatie waarmee de identiteit kan worden geverifieerd, zoals creditcardgegevens, een telefoonnummer waarop iemand bereikbaar is of een kopie van een identiteitsbewijs. ­Deze laatste moet dan wel worden ontdaan van informatie waarmee identiteitsfraude kan worden gepleegd, zoals geboortedatum en burgerservicenummer (BSN). Daarnaast kunnen mechanismen als step-up authentication of knowledge-based authentication worden ingezet, zodra de hoedanigheid van de transactie dat vereist.

 

Risico’s

Omdat de gebruikers van social networks zeer vaak een mobiel apparaat gebruiken om toegang te verkrijgen tot de services van een organisatie, kunnen de extra mogelijkheden worden aangewend die smartphones of ­tablets bieden om meer zekerheid te verkrijgen over iemands identiteit. Gegevens als ­IP-adres, GPS-locatie, cookie, flash-object en X.509-certificaat zijn allemaal bruikbaar voor dit doel. Ook het tijdstip, de aard van de transactie (is deze gebruikelijk voor de betreffende identiteit) en de frequentie van aanmelden verschaffen extra informatie over de identiteit. Ten slotte kan de identiteit van het apparaat waarmee toegang wordt gezocht als extra verificatie worden aangewend ­(device fingerprinting). Smartphones bieden ook de mogelijkheid om sms-authenticatie toe te passen.

Het is overigens goed om te bedenken dat er alternatieve identityproviders bestaan in de vorm van overheden, commerciële aanbieders en diverse samenwerkingsverbanden, al hebben die stuk voor stuk een heel wat ­beperkter bereik. Daar staat tegenover dat ­identityproviders van overheidswege wel veel betrouwbaarder zijn. In Nederland vormt het toekomstige eID Stelsel een ­mogelijk alternatief.

De conclusie moet zijn dat social identities alleen toelaatbaar zijn voor usecases met een laag risicoprofiel. Zijn er hogere risico’s in het spel, dan moet meer zekerheid over de ­identiteit worden verkregen en moet de ­mogelijkheid voorhanden zijn om van de ­gebruiker te eisen dat extra informatie wordt aangedragen om de identiteit te verifiëren. Verder lijken social identities het meest ­geschikt voor klantrelaties van voorbijgaande aard.

Open Authorization

OAuth (Open Authorization) is de onderliggende specificatie van de techniek die social network login mogelijk maakt. Met OAuth kunnen gebruikers een app of webapplicatie toegang verlenen tot bepaalde eigen gegevens zonder daarbij hun accountgegevens, zoals het wachtwoord, te hoeven prijsgeven. In plaats daarvan wordt gebruik gemaakt van een token dat alle relevante informatie bevat. In een wereld van sociale media en mobiele apparaten waarin het delen van informatie gemeengoed is, is het van groot belang dat dit op een veilige en nauwkeurige wijze gebeurt. OAuth is transparant voor gebruikers, met andere woorden, het achterliggende mechanisme blijft onzichtbaar.

Voordat OAuth bestond, was het alleen mogelijk om applicaties toegang te verlenen tot gegevens van gebruikers door het wachtwoord te verschaffen. Dat had grote nadelen: de derde partij verkreeg volledige toegang tot het account van de gebruiker en daarmee tot al zijn gegevens, de toegang was permanent (kon alleen worden ontzegd door het wachtwoord te veranderen) en het wachtwoord liep gevaar blootgesteld te worden aan onbevoegden.

Om de genoemde problemen het hoofd te bieden bedachten grote internet-partijen, zoals Facebook, Google en Flickr, aanvankelijk hun eigen oplossingen. Deze oplossingen boden weliswaar een vergelijkbare functionaliteit als OAuth, maar waren niet compatibel met elkaar. OAuth is speciaal ontwikkeld als open specificatie om de hier beschreven functionaliteit te kunnen bieden, eerst als idee van een op zichzelf staande discussiegroep, later als formele RFC (Request For Comment) van de IETF (Internet Engineering Task Force).

OAuth werkt samen met HTTP (HyperText Transfer Protocol) en maakt gebruik van dezelfde functies om informatie op te halen of af te handelen. Het biedt ontwikkelaars zodoende flexibele mogelijkheden in zeer diverse scenario’s.

De huidige versie van OAuth (versie 2) is niet neerwaarts compatibel met de voorgaande variant van OAuth (versie 1). Een belangrijk verschil tussen beide versies is de wijze waarop de berichten worden beveiligd die nodig zijn om informatie te verzenden. OAuth versie 1 maakt hiervoor gebruik van het digitaal ondertekenen van de afzonderlijke berichten, wat lastig te implementeren is. OAuth versie 2 daarentegen werkt goed samen met TLS/SSL (Transport Layer Security/Secure Sockets Layer), de algemene standaard voor het beveiligen van internetverkeer. Binnen de OAuth-specificatie speelt een aantal entiteiten een rol (zie tabel).

Zoals uit al het voorgaande blijkt, vormt OAuth een protocolstructuur die zowel voor (het delegeren van) autorisatie als authenticatie kan worden toegepast. OAuth kan met een developer toolkit van het betreffende social network worden geïmplementeerd, maar wordt ook ondersteund door veel leveranciers van producten of services voor identity & access-management.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag