Same-device- og cross-device-flyt forklart
Hver gang en lommebok beviser noe overfor et nettsted, må de to finne hverandre. Noen ganger er de allerede på samme telefon, og overgangen er ett enkelt trykk. Andre ganger står nettstedet på en pult og lommeboken ligger i en lomme, og den eneste broen mellom dem er en kode på skjermen. Dette er same-device- og cross-device-flyten, og nesten alle praktiske spørsmål om digitale credentials handler til syvende og sist om hvilken av de to du befinner deg i.
To former av samme utveksling
Det de to flytene har felles, er alt som betyr noe for virksomheten: det samme spørsmålet stilles, den samme personen godkjenner det, og det samme beviset kommer tilbake. Hva dere har lov til å be om, eller hva dere kan stole på etterpå, avhenger ikke av hvilken flyt dere er i.
Det som skiller dem, er ruten. I den ene er lommeboken ett trykk unna og gir svaret rett tilbake til siden som spurte. I den andre går svaret fra en annen enhet til serverne deres, og siden personen ser på, må få beskjed om at det har kommet.
Samme enhet
Én telefon. Nettsted og lommebok på samme skjerm.
- Besøkeren er på nettstedet i nettleseren på telefonen og ber om å bevise noe.
- Nettstedet åpner lommeboken med en deep link eller en omdirigering.
- Lommeboken viser hvem som spør og hvorfor, og besøkeren godkjenner.
- Lommeboken sender besøkeren tilbake til nettstedet med svaret, i den samme nettleserøkten som startet utvekslingen.
På tvers av to enheter
To enheter. Nettstedet på en datamaskin, lommeboken på en telefon.
- Besøkeren er på nettstedet i nettleseren på en datamaskin og ber om å bevise noe.
- Nettstedet viser en QR-kode som inneholder forespørselen.
- Lommeboken på telefonen skanner den, viser hvem som spør, og besøkeren godkjenner.
- Lommeboken sender svaret til nettstedets backend, som gir beskjed til siden på datamaskinen om at utvekslingen er ferdig.
Når hver av dem skjer
Dere får ikke velge. En kunde som åpner onboardingsiden deres på telefonen på vei til jobb, er i en same-device-flyt. Den samme kunden, som fullfører det samme skjemaet ved en pult neste morgen, er i en cross-device-flyt. Lommeboken bor på en telefon, så flyten følger der resten av arbeidet foregår.
Derfor beskriver begge protokollene i det europeiske økosystemet begge flytene. Fremvisning, der dere ber noen bevise noe, navngir de to flytene eksplisitt. Utstedelse, der dere gir noen et credential, gjør det samme skillet for tilbudet som starter den: det kan dukke opp på enheten lommeboken ligger på, eller komme via en hvilken som helst annen vei, helt ned til et brev med en trykt kode.
En tjeneste som bare brukes internt i organisasjonen deres, på administrerte datamaskiner, kan med god grunn starte med én flyt. Alt en innbygger eller kunde bruker på egne premisser, trenger begge, og en tjeneste som bare fungerer på én måte, blir rapportert som ødelagt, ikke som ustøttet.
Hva hver av dem koster brukeren
Same-device er den korteste veien. Det er ingen ekstra skjerm, ingen kamera og ikke noe øyeblikk der blikket flyttes fra én enhet til en annen, og personen havner tilbake der de startet. Når det feiler, feiler det som regel tidlig og synlig: ingen lommebok er installert, eller lenken åpner noe som ikke er en lommebok i det hele tatt.
Cross-device koster en skanning, men gir noe reelt tilbake. Personen blir værende på den store skjermen der de fylte ut et langt skjema, leste en kontrakt eller sammenlignet alternativer, og bare selve beviset flyttes til telefonen. For alt som krever mer enn et minutts skriving, er det det beste stedet å være.
Feilene her er stillere og verdt å designe for. En kode som gikk ut mens noen lette etter telefonen, en telefon uten dekning, et kamera som ikke vil fokusere. Siden som viser koden, bør si hvor lenge den er gyldig, tilby en ny uten å miste skjemaet under, og aldri la personen lure på om noe har skjedd.
Der de virkelig skiller seg: sikkerhet
I en same-device-flyt kommer svaret tilbake samme vei som personen gikk: en omdirigering, på enheten lommeboken kjører på, inn i nettleserøkten som startet utvekslingen. Noen som kopierer forespørselen fra sin egen skjerm, har ingen mulighet til å motta resultatet, fordi det leveres til enheten som godkjente.
I en cross-device-flyt kommer svaret ikke tilbake gjennom nettleseren i det hele tatt. Det går fra telefonen til serverne deres, utenfor synsfeltet til siden som viste koden. Det er der hullet er: med mindre dere knytter koden til økten som viste den, kan ikke tjenesten deres skille personen foran seg fra noen som satte den samme koden foran et offer og ventet.
Angrepet har et navn og en løsning. Koden må tilhøre én økt og bare én, og et resultat som kommer inn for en hvilken som helst annen økt, må avvises. Det krever litt omtanke i designfasen og er et kjent hull hvis det hoppes over, og derfor skrev IETF en best current practice for cross-device-flyter i stedet for å overlate det til hver enkelt implementasjon.
Den andre risikoen er phishing, og den hører til selve koden. En firkant i svart og hvitt forteller ikke personen noe om hvem som er i den andre enden, så en kode trykt på et klistremerke og limt over en ekte er et troverdig angrep. Forsvaret er at lommeboken, ikke koden, navngir organisasjonen som spør og lister opp nøyaktig hva den vil ha før noe deles. Utstedelse legger til én lås til: et tilbud kan kreve en kort kode levert via kanalen som allerede har identifisert personen, slik at et tilbud som fanges opp underveis, ikke kan løses inn av noen andre.
Hva dette betyr for deg
Tillitspart
Planlegg for begge fra starten av. Ekstraarbeidet ligger i frontend og i å knytte koden til en økt, ikke i en ny integrasjon, og det er nettopp å ettermontere den koblingen senere som går galt.
Utsteder
Bestem hvordan tilbudet deres når folk. På skjermen ved siden av en innlogging, i en e-post eller på papir: hver av dem havner i en ulik flyt, og de som forlater kanalen deres, er de som trenger en egen kode for å løses inn.
Lommebokinnehaver
Les det lommeboken viser deg, ikke det siden eller koden påstår. Lommeboken er det eneste stedet som navngir hvem som spør og hva de vil ha, og det er det siste punktet der du kan si nei.
Relaterte begreper
Ofte stilte spørsmål
Hvem bestemmer hvilken flyt som brukes?
Situasjonen gjør det, ikke en innstilling. Hvis personen allerede er på enheten lommeboken ligger på, sender nettstedet dem direkte videre. Hvis de sitter ved en datamaskin og lommeboken ligger i lomma, er en kode å skanne den eneste veien over. En tjeneste som er åpen for publikum, vil møte begge i løpet av den første uken.
Betyr støtte for begge at alt må bygges to ganger?
Nei. Forespørselen dere sender og svaret dere kontrollerer, er det samme i begge tilfeller. Forskjellen ligger i hvordan forespørselen når lommeboken og hvordan svaret kommer tilbake til siden deres: en omdirigering nettleseren følger, eller en kode på skjermen pluss en måte for siden å få vite at utvekslingen er ferdig. I praksis er det én ekstra vei i frontend, ikke en ny integrasjon.
Er det trygt å bruke en QR-kode til dette?
Ja, når utvekslingen rundt den er bygget riktig. En kode alene forteller ikke personen noe om hvem som spør, så to ting må være på plass: lommeboken må vise identiteten til organisasjonen som spør før noe deles, og tjenesten deres må avvise et svar som kommer inn for en annen økt enn den som viste koden. Begge deler er etablert praksis, og begge er beskrevet i spesifikasjonene.
Er en kontroll ved en skranke en cross-device-flyt?
Nei, det er et tredje tilfelle. Både same-device og cross-device beskriver en utveksling over internett. En kontroll ansikt til ansikt, der de to enhetene holdes ved siden av hverandre, bruker i stedet en nærhetsstandard over Bluetooth eller NFC. For den som holder telefonen ser det likt ut, men ingenting går via nettstedet deres.
Kilder
Denne siden er kun til informasjon og utgjør ikke juridisk rådgivning. For autoritativ veiledning, se OpenID- og IETF-spesifikasjonene direkte.