Same-device és cross-device folyamatok elmagyarázva
Valahányszor egy tárca igazol valamit egy weboldalnak, a kettőnek meg kell találnia egymást. Néha már ugyanazon a telefonon vannak, és az átadás egyetlen koppintás. Máskor a weboldal az asztalon van, a tárca a zsebben, és az egyetlen híd köztük egy kód a képernyőn. Ezek a same-device és a cross-device folyamatok, és a digitális igazolványokkal kapcsolatos szinte minden gyakorlati kérdés oda vezet vissza, hogy éppen melyikben van.
Ugyanannak a cserének két formája
A két folyamatban közös minden, ami az üzlet szempontjából számít: ugyanaz a kérdés hangzik el, ugyanaz a személy hagyja jóvá, és ugyanaz a bizonyíték érkezik vissza. Semmi abból, amit kérdezhet, vagy amire utána támaszkodhat, nem függ attól, melyik folyamatban van.
Az útvonal különbözik. Az egyikben a tárca egy koppintásnyira van, és a választ közvetlenül a kérdező oldalnak adja vissza. A másikban a válasz egy második eszközről jut el a szervereihez, és az oldalnak, amelyet a felhasználó néz, jelezni kell, hogy megérkezett.
Same-device
Egy telefon. A weboldal és a tárca ugyanazon a képernyőn.
- A látogató a telefonja böngészőjében van az oldalon, és igazolnia kell valamit.
- Az oldal deep linkkel vagy átirányítással megnyitja a tárcát.
- A tárca megmutatja, ki kérdez és miért, a látogató pedig jóváhagyja.
- A tárca a válasszal visszairányít az oldalra, ugyanabba a böngészőmunkamenetbe, amelyben minden elkezdődött.
Cross-device
Két eszköz. A weboldal számítógépen, a tárca telefonon.
- A látogató a számítógép böngészőjében van az oldalon, és igazolnia kell valamit.
- Az oldal megjelenít egy QR-kódot, amely a kérést hordozza.
- A telefonon lévő tárca beolvassa, megmutatja, ki kérdez, a látogató pedig jóváhagyja.
- A tárca elküldi a választ az oldal háttérrendszerének, amely jelzi a számítógépes oldalnak, hogy a csere lezárult.
Mikor melyik történik
Nem Ön választ. Az az ügyfél, aki munkába menet a telefonján nyitja meg a regisztrációs oldalát, same-device folyamatban van. Ugyanez az ügyfél, amikor másnap reggel az íróasztalnál fejezi be ugyanazt az űrlapot, cross-device folyamatban van. A tárca a telefonon él, így a folyamat oda igazodik, ahol a munka többi része éppen zajlik.
Ezért írja le az európai ökoszisztéma mindkét protokollja mindkét folyamatot. A bemutatás, amikor valakit arra kér, hogy igazoljon valamit, kifejezetten megnevezi a két folyamatot. A kibocsátás, amikor valakinek igazolványt ad át, ugyanezt a megkülönböztetést teszi az ajánlatnál, amellyel minden kezdődik: megjelenhet azon az eszközön, amelyen a tárca van, vagy bármilyen más úton érkezhet, akár egy nyomtatott kódot tartalmazó levélben is.
Egy olyan szolgáltatás, amelyet csak a saját szervezetén belül, felügyelt asztali gépeken használnak, észszerűen indulhat egyetlen folyamattal. Mindennek, amihez egy állampolgár vagy ügyfél a saját feltételei szerint jut el, mindkettőre szüksége van, és az egyféleképpen működő szolgáltatást hibásnak fogják jelenteni, nem pedig nem támogatottnak.
Mibe kerül a felhasználónak az egyik és a másik
A same-device a rövidebb út. Nincs második képernyő, nincs kamera, nincs pillanat, amikor a tekintet egyik eszközről a másikra vándorol, és a felhasználó ott köt ki, ahonnan elindult. Ha hibázik, általában korán és láthatóan teszi: nincs telepítve tárca, vagy a link olyasmit nyit meg, ami egyáltalán nem tárca.
A cross-device egy beolvasásba kerül, de valódi előnyt ad. A felhasználó a nagy képernyőnél marad, ahol egy hosszú űrlapot töltött ki, szerződést olvasott vagy lehetőségeket hasonlított össze, és csak maga a bizonyíték kerül át a telefonra. Mindenhez, ami egy percnél több gépelést igényel, ez a jobb hely.
A hibái csendesebbek, és érdemes tervezéskor számolni velük. Egy kód, amely lejárt, miközben valaki a telefonját kereste, egy térerő nélküli telefon, egy kamera, amely nem fókuszál. A kódot megjelenítő oldal mondja meg, meddig érvényes, kínáljon új kódot az alatta lévő űrlap elvesztése nélkül, és soha ne hagyja a felhasználót találgatni, hogy történt-e valami.
Ahol a kettő valóban különbözik: biztonság
Same-device folyamatban a válasz azon az úton tér vissza, amelyen a felhasználó elindult: átirányításként, azon az eszközön, amelyen a tárca fut, abba a böngészőmunkamenetbe, amely a cserét elindította. Aki a saját képernyőjéről lemásolja a kérést, nem tudja megkapni az eredményt, mert az a jóváhagyást végző eszközre érkezik.
Cross-device folyamatban a válasz egyáltalán nem a böngészőn keresztül tér vissza. A telefonról a szervereihez jut, a kódot megjelenítő oldal látókörén kívül. Ez a rés: ha nem köti a kódot az azt megjelenítő munkamenethez, a szolgáltatása nem tudja megkülönböztetni az előtte ülő személyt valakitől, aki ugyanazt a kódot egy áldozat elé tette, és várt.
Ennek a támadásnak neve és ellenszere van. A kódnak egyetlen munkamenethez kell tartoznia, és a bármely más munkamenethez érkező eredményt el kell utasítani. Tervezéskor ez néhány sornyi végiggondolás, ha kimarad, akkor ismert biztonsági rés, ezért az IETF a cross-device folyamatokra külön bevált gyakorlatot (Best Current Practice) írt, ahelyett hogy minden implementációra bízta volna.
A második kockázat az adathalászat, és ez magához a kódhoz tartozik. Egy fekete-fehér négyzet semmit sem árul el arról, ki van a másik oldalon, így egy matricára nyomtatott és a valódira ragasztott kód hihető támadás. A védelem az, hogy a kérdező szervezetet nem a kód, hanem a tárca nevezi meg, és sorolja fel pontosan, mit kér, még mielőtt bármi megosztásra kerülne. A kibocsátás még egy zárat tesz hozzá: egy ajánlat megkövetelhet egy rövid kódot, amelyet azon a csatornán kézbesítenek, amely a személyt már azonosította, így az útközben elfogott ajánlatot senki más nem tudja beváltani.
Mit jelent ez Önnek
Bizalmat adó fél
Tervezzen mindkettővel kezdettől fogva. A többletmunka a frontendben és a kód munkamenethez kötésében van, nem egy második integrációban, és a kötés utólagos beépítése az a rész, amely félresikerül.
Kibocsátó
Döntse el, hogyan jut el az ajánlata az emberekhez. A képernyőn egy bejelentkezés mellett, e-mailben vagy papíron: mindegyik más folyamatba vezet, és amelyik elhagyja az Ön csatornáját, annak beváltásához külön kód kell.
Tárcabirtokos
Azt olvassa el, amit a tárca mutat, ne azt, amit az oldal vagy a kód állít. A tárca az egyetlen hely, amely megnevezi, ki kérdez és mit akar, és ez az utolsó pont, ahol még nemet mondhat.
Kapcsolódó fogalmak
Gyakran ismételt kérdések
Ki dönti el, melyik folyamat fut?
A helyzet dönt, nem egy beállítás. Ha a felhasználó már azon az eszközön van, amelyen a tárcája is, az oldal közvetlenül átadja. Ha számítógép előtt ül, a tárca pedig a zsebében van, az egyetlen átjáró egy beolvasható kód. Egy nyilvános szolgáltatás már az első héten mindkettővel találkozik.
Ha mindkettőt támogatjuk, mindent kétszer kell megépíteni?
Nem. A kérés, amelyet elküld, és a válasz, amelyet ellenőriz, mindkét esetben ugyanaz. Az különbözik, hogyan jut el a kérés a tárcához, és hogyan tér vissza a válasz az oldalára: egy átirányítás, amelyet a böngésző követ, vagy egy kód a képernyőn, és mellé egy mód, hogy az oldal megtudja, a csere befejeződött. A gyakorlatban ez egy további útvonal a frontendben, nem egy második integráció.
Biztonságos erre QR-kódot használni?
Biztonságos, ha a körülötte zajló csere megfelelően van felépítve. A kód önmagában semmit sem árul el arról, ki kérdez, ezért két feltételnek teljesülnie kell: a tárcának bármilyen adatmegosztás előtt meg kell mutatnia a kérdező szervezet személyazonosságát, a szolgáltatásának pedig el kell utasítania azt a választ, amely nem ahhoz a munkamenethez érkezik, amely a kódot megjelenítette. Mindkettő bevett gyakorlat, és mindkettőt rögzítik a specifikációk.
Cross-device folyamat-e az ügyfélpultnál végzett ellenőrzés?
Nem, az egy harmadik eset. A same-device és a cross-device folyamat egyaránt interneten zajló cserét ír le. A személyes ellenőrzés, amikor a két eszközt egymás mellé tartják, ehelyett Bluetooth vagy NFC alapú közelségi szabványt használ. A telefont tartó személy számára hasonlónak tűnik, de semmi sem halad át a weboldalán.
Források
Ez az oldal tájékoztató jellegű, és nem minősül jogi tanácsadásnak. Hiteles útmutatásért forduljon közvetlenül az OpenID és az IETF specifikációihoz.