Forløb på samme enhed og på tværs af enheder forklaret
Hver gang en tegnebog beviser noget over for en hjemmeside, skal de to finde hinanden. Nogle gange er de allerede på den samme telefon, og overdragelsen er et enkelt tryk. Andre gange står hjemmesiden på et skrivebord og tegnebogen ligger i en lomme, og den eneste bro mellem dem er en kode på skærmen. Det er forløbene på samme enhed og på tværs af enheder, og næsten alle praktiske spørgsmål om digitale credentials vender tilbage til, hvilket af de to du befinder dig i.
To former for den samme udveksling
Det, de to forløb har til fælles, er alt det, der betyder noget for forretningen: det samme spørgsmål stilles, den samme person godkender, og det samme bevis kommer tilbage. Hvad du må spørge om, og hvad du kan stole på bagefter, afhænger slet ikke af, hvilket forløb du er i.
Forskellen er ruten. I det ene er tegnebogen ét tryk væk og giver svaret direkte tilbage til den side, der spurgte. I det andet rejser svaret fra en anden enhed til dine servere, og den side, personen kigger på, skal have besked om, at det er kommet frem.
Samme enhed
Én telefon. Hjemmeside og tegnebog på samme skærm.
- Den besøgende er på siden i telefonens browser og vil bevise noget.
- Siden åbner tegnebogen med et deep link eller en omdirigering.
- Tegnebogen viser, hvem der spørger og hvorfor, og den besøgende godkender.
- Tegnebogen sender den besøgende tilbage til siden med svaret, i den samme browsersession, som startede forløbet.
På tværs af enheder
To enheder. Hjemmeside på en computer, tegnebog på en telefon.
- Den besøgende er på siden i en browser på computeren og vil bevise noget.
- Siden viser en QR-kode, der indeholder anmodningen.
- Tegnebogen på telefonen scanner koden, viser, hvem der spørger, og den besøgende godkender.
- Tegnebogen sender svaret til sidens backend, som giver besked til siden på computeren om, at udvekslingen er gennemført.
Hvornår hvert forløb opstår
Du kan ikke selv vælge. En kunde, der åbner din onboardingside på telefonen på vej til arbejde, er i et forløb på samme enhed. Den samme kunde, der gør den samme formular færdig ved et skrivebord næste morgen, er i et forløb på tværs af enheder. Tegnebogen bor på en telefon, så forløbet følger med, uanset hvor resten af arbejdet foregår.
Derfor beskriver begge protokoller i det europæiske økosystem begge forløb. Præsentation, hvor du beder nogen om at bevise noget, nævner eksplicit de to forløb. Udstedelse, hvor du giver nogen et credential, laver samme skelnen for det tilbud, der starter processen: det kan dukke op på den enhed, tegnebogen er på, eller komme ad en hvilken som helst anden vej, helt ned til et brev med en trykt kode.
En tjeneste, der kun bruges internt i din organisation på administrerede computere, kan fint starte med ét forløb. Alt, hvad en borger eller kunde tilgår på egne præmisser, skal kunne begge, og en tjeneste, der kun virker på én måde, vil blive meldt som defekt snarere end som ikke understøttet.
Hvad hvert forløb koster brugeren
Samme enhed er den korteste vej. Der er ingen anden skærm, intet kamera og intet øjeblik, hvor man kigger fra den ene enhed til den anden, og personen ender, hvor vedkommende startede. Når det fejler, sker det som regel tidligt og synligt: der er ingen tegnebog installeret, eller linket åbner noget, der slet ikke er en tegnebog.
På tværs af enheder koster en scanning, men giver noget reelt til gengæld. Personen bliver på den store skærm, hvor vedkommende var i gang med at udfylde en lang formular, læse en kontrakt eller sammenligne muligheder, og kun selve beviset flytter over på telefonen. Til alt, der kræver mere end et minuts tastearbejde, er det det bedste sted at være.
Fejlene her er mere stille og værd at designe efter. En kode, der udløb, mens nogen ledte efter telefonen, en telefon uden forbindelse, et kamera, der ikke vil fokusere. Siden med koden bør vise, hvor længe den er gyldig, tilbyde en ny uden at miste formularen nedenunder og aldrig efterlade personen i tvivl om, hvorvidt der skete noget.
Hvor de to reelt adskiller sig: sikkerhed
I et forløb på samme enhed kommer svaret tilbage ad den vej, personen gik: en omdirigering på den enhed, tegnebogen kører på, ind i den browsersession, der startede udvekslingen. Den, der kopierer anmodningen fra sin egen skærm, har ingen mulighed for at modtage resultatet, fordi det leveres til den enhed, der godkendte.
I et forløb på tværs af enheder kommer svaret slet ikke tilbage via browseren. Det går fra telefonen til dine servere, uden for synsfeltet af den side, der viste koden. Det er hullet: medmindre du knytter koden til den session, der viste den, kan din tjeneste ikke skelne mellem personen foran den og en, der har lagt den samme kode foran et offer og ventet.
Det angreb har et navn og et modtræk. Koden skal tilhøre én session og kun én, og et resultat, der ankommer til en anden session, skal afvises. Det kræver lidt omtanke i designfasen og er et kendt hul, hvis det springes over, og derfor har IETF skrevet en best current practice for forløb på tværs af enheder i stedet for at overlade det til den enkelte implementering.
Den anden risiko er phishing, og den hører til selve koden. Et sort-hvidt kvadrat fortæller intet om, hvem der sidder i den anden ende, så en kode trykt på et klistermærke og sat hen over en ægte kode er et troværdigt angreb. Forsvaret er, at det er tegnebogen og ikke koden, der navngiver den organisation, der spørger, og oplister præcis, hvad den vil have, før noget deles. Udstedelse tilføjer en ekstra lås: et tilbud kan kræve en kort kode, der leveres via den kanal, som allerede har identificeret personen, så et tilbud, der opfanges undervejs, ikke kan indløses af andre.
Hvad det betyder for dig
Tillidspart
Planlæg begge fra starten. Det ekstra arbejde ligger i din frontend og i at binde koden til en session, ikke i en ekstra integration, og det er netop bindingen, der går galt, når den eftermonteres.
Udsteder
Beslut, hvordan dit tilbud når frem til folk. På skærmen ved siden af et login, i en e-mail eller på papir: hver vej lander i et andet forløb, og de veje, der forlader din kanal, er dem, der kræver en separat kode for at blive indløst.
Tegnebogsindehaver
Læs, hvad tegnebogen viser dig, ikke hvad siden eller koden påstår. Tegnebogen er det eneste sted, der navngiver, hvem der spørger, og hvad de vil have, og det er det sidste tidspunkt, hvor du kan sige nej.
Relaterede begreber
Ofte stillede spørgsmål
Hvem bestemmer, hvilket forløb der bruges?
Det gør situationen, ikke en indstilling. Er personen allerede på den enhed, tegnebogen ligger på, overdrager siden direkte. Sidder vedkommende ved en computer med tegnebogen i lommen, er den eneste vej over en kode, der skal scannes. En tjeneste, der er åben for offentligheden, møder begge inden for den første uge.
Betyder understøttelse af begge, at alt skal bygges to gange?
Nej. Den anmodning, du sender, og det svar, du kontrollerer, er de samme i begge tilfælde. Forskellen ligger i, hvordan anmodningen når frem til tegnebogen, og hvordan svaret kommer tilbage til din side: en omdirigering, som browseren følger, eller en kode på skærmen plus en måde, hvorpå siden får at vide, at udvekslingen er afsluttet. I praksis er det én ekstra vej i din frontend, ikke en ekstra integration.
Er det sikkert at bruge en QR-kode til dette?
Det er sikkert, når udvekslingen omkring den er bygget ordentligt. En kode fortæller i sig selv intet om, hvem der spørger, så to ting skal være på plads: tegnebogen skal vise identiteten på den organisation, der spørger, før noget deles, og din egen tjeneste skal afvise et svar, der ankommer til en anden session end den, der viste koden. Begge dele er almindelig praksis, og begge er beskrevet i specifikationerne.
Er en kontrol ved en skranke et forløb på tværs af enheder?
Nej, det er et tredje tilfælde. Både samme enhed og på tværs af enheder beskriver en udveksling over internettet. En kontrol ansigt til ansigt, hvor de to enheder holdes ved siden af hinanden, bruger i stedet en nærhedsstandard over Bluetooth eller NFC. For personen med telefonen ser det ens ud, men intet går via din hjemmeside.
Kilder
Denne side er til orientering og udgør ikke juridisk rådgivning. For autoritativ vejledning bør du læse OpenID- og IETF-specifikationerne direkte.