Innovatív beépített hitelesítés Google, Facebook és Apple segítségével

Beépített bejelentkezés magánügyfeleknek

A Beépített bejelentkezés akkor hasznos, ha egy weboldalon vagy alkalmazásban a felhasználók Google, Facebook vagy Apple fiókkal tudnak belépni, külön jelszó létrehozása nélkül. A feladat lényege nem csak egy gomb elhelyezése. A fejlesztőnek össze kell kötni a külső fiókokat a meglévő rendszerrel, kezelni kell az új és régi felhasználókat, a hibás belépéseket, az adatokat és a biztonsági beállításokat. Én azt látom, hogy sok magánügyfél először egyszerű apróságnak gondolja ezt, aztán akkor derül ki a nehézség, amikor az egyik szolgáltató működik, a másik pedig nem engedélyezi az átirányítást.

A Qjob.hu oldalán magánszakembert lehet keresni ilyen online fejlesztési munkára. Itt a megrendelő általában nem teljes céges fejlesztőcsapatot keres, hanem egy olyan szabadúszó programozót, aki érti a beléptetési folyamatot, tud kérdezni, és távolról is végig tudja vinni a beállítást. A jó munka végén a felhasználó számára egyszerű marad a folyamat. Rákattint a választott fiókra, engedélyez, majd belép. A háttérben viszont sok ellenőrzés fut.

A közösségi belépés különösen akkor fontos, ha a szolgáltatás gyors regisztrációt igényel. Egy kis webes eszköz, előfizetéses felület, hirdetési oldal, ügyfélkapu vagy mobilalkalmazás sok felhasználót veszíthet, ha a regisztráció hosszú. De ez nem jelenti azt, hogy minden esetben három belépési mód kell. Szerintem először azt kell eldönteni, kik használják a rendszert, milyen eszközön lépnek be, és van-e már meglévő jelszavas fiókrendszer.

Beépített belépés Google, Facebook és Apple fiókkal

A beépített belépés három gyakori iránya a Google, a Facebook és az Apple azonosítás. Mindegyik hasonlónak látszik, de a fejlesztésben eltérő szabályokkal működik. A Google belépés sok webes felületen alapmegoldás, mert sok felhasználónak van ilyen fiókja. A Facebook belépés inkább akkor indokolt, ha a célközönség aktívan használja ezt a fiókot. Az Apple belépés akkor válik fontossá, ha az alkalmazás iOS felhasználóknak is készül, vagy már más külső belépési mód is szerepel az alkalmazásban.

A szakember először megnézi, milyen rendszerbe kell beilleszteni a belépést. Más a feladat egy kész tartalomkezelőnél, más egy egyedi fejlesztésű weboldalnál, és megint más egy mobilalkalmazásnál. Fontos a jelenlegi adatbázis is. Ha már vannak ügyfelek, akkor meg kell oldani, hogy ugyanazzal az e-mail címmel ne jöjjön létre két külön fiók. Ez gyakori gond. Volt olyan eset, amikor egy ügyfél azért kért javítást, mert a régi jelszavas fiók és az új Google belépés két külön felhasználót hozott létre. A fizetési előzmények az egyikben voltak, a belépés a másikban. Ezt utólag javítani kellett.

Az online beléptetés nem csak kényelmi funkció. Adatvédelmi és biztonsági kérdés is. A fejlesztőnek figyelnie kell arra, milyen adatot kér le a külső szolgáltatótól, hogyan menti el az azonosítót, és mi történik, ha a felhasználó visszavonja az engedélyt. A jó megoldás nem gyűjt felesleges adatot. Csak azt használja, amire tényleg szükség van a fiók létrehozásához vagy azonosításához.

Beépített bejelentkezés árak

Az ár főleg attól függ, hány belépési mód kell, milyen állapotban van a rendszer, és kell-e hibajavítás a meglévő fiókkezelésben. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a beállítás elsőre működhet, de később jönnek elő a hibák. Például lejáró kulcsok, hibás átirányítás, rosszul kezelt felhasználói adatok, vagy az, hogy mobilon másképp viselkedik a belépés, mint böngészőben.

Tapasztalatom szerint az egyszerű Google belépés ára nem ugyanaz, mint egy teljes, három szolgáltatós fiókrendszer ára. A megrendelőnek érdemes külön rákérdeznie, hogy az ár tartalmazza-e a tesztelést, a hibák javítását, a szolgáltatói fiókok beállítását és az átadási leírást. Ha ezek nincsenek tisztázva, később vita lehet abból, hogy mi számít kész munkának.

Online munka menete és átadás

A munka távolról is jól szervezhető, ha a megrendelő előre összegyűjti a hozzáféréseket és leírja a célt. Nem kell hosszú leírás. Elég megadni, milyen felületen kell beépíteni a belépést, milyen technológiával készült a rendszer, van-e már regisztráció, és mely fiókokkal lehessen belépni. A fejlesztő ezután ellenőrzi a kódot vagy a beállításokat, majd javaslatot ad a megoldásra.

A folyamat általában több lépésből áll. Először technikai felmérés történik. Utána következik a külső szolgáltatói alkalmazások létrehozása vagy ellenőrzése. Ezután jön a kódolás, a visszahívási címek beállítása, a jogosultságok szűkítése, majd a tesztelés. A végén a szakember átadja a kész funkciót, és jó esetben röviden leírja, hol vannak a kulcsok, milyen beállításokhoz nem szabad nyúlni, és milyen hibákat kell figyelni a jövőben.

A kommunikáció lehet üzenetben, videóhívásban vagy feladatkezelőn keresztül. Szerintem a legjobb, ha minden fontos döntés írásban is megmarad. Például az, hogy a felhasználó e-mail címe kötelező adat-e, mi történik, ha az Apple elrejti az e-mail címet, vagy hogyan kell kezelni a már meglévő fiókokat. Ezek apróságnak tűnnek, de később komoly zavart okozhatnak.

Szabadúszó fejlesztő kiválasztása

A szabadúszó fejlesztő kiválasztásánál nem az a legfontosabb, hogy valaki általánosságban tud programozni. Olyan szakember kell, aki látott már külső azonosítást, érti a jogosultságokat, és nem csak bemásol egy kész kódrészletet. Kérni lehet korábbi példát, de sok beléptetési munka nem látszik nyilvánosan. Ezért jobb konkrét kérdéseket feltenni.

Érdemes megkérdezni, hogyan kezeli a meglévő felhasználókat, mit tesz hibás e-mail cím esetén, hogyan teszteli a belépést több eszközön, és milyen hozzáférésekre lesz szüksége. A jó szakember nem kér feleslegesen teljes hozzáférést mindenhez. És nem ígéri azt, hogy minden fél óra alatt kész lesz. Lehet gyors munka, de a biztonságos beépített bejelentkezés ritkán csak egy gomb.

Sokan ott hibáznak, hogy csak az árat nézik. Közben a belépési rendszer a teljes szolgáltatás kapuja. Ha rosszul működik, a felhasználó nem jut be, vagy rossz fiókba kerül. Ez közvetlen veszteség. Egy magánügyfélnek ezért azt javaslom, hogy ne csak a díjat kérje el, hanem a feladat határát is. Mi lesz beállítva, mi lesz tesztelve, és mit kap meg a végén.

Gyakori hibák a közösségi belépésnél

A közösségi belépés egyik leggyakoribb hibája a rossz átirányítási cím. Ilyenkor a felhasználó engedélyez, de a rendszer nem tud visszatérni a weboldalra vagy az alkalmazásba. A másik gyakori gond a rosszul kezelt környezet. A tesztoldalon működik minden, az éles oldalon pedig nem. Ennek oka sokszor az, hogy külön kulcsok, külön címek és külön engedélyek tartoznak a teszt és az éles rendszerhez.

Hiba az is, ha a fejlesztő túl sok adatot kér le a felhasználóról. Egy egyszerű azonosításhoz általában nincs szükség sok személyes adatra. A túl széles jogosultság bizalmatlanságot kelthet, és adatvédelmi szempontból is rossz irány. A beépített bejelentkezés akkor jó, ha a felhasználó nem érzi bonyolultnak, de a háttérben mégis szabályosan működik.

Van egy másik probléma is. Néhány megrendelő azt várja, hogy a Google, Facebook és Apple belépés után már nem kell saját fiókrendszer. Ez nem pontos. A külső szolgáltató az azonosítást segíti, de a saját rendszerben továbbra is kell felhasználói rekord, jogosultság, profil, előfizetés vagy rendelési kapcsolat, ha az oldal ilyen adatokat kezel. A fejlesztő feladata az, hogy ezt a két világot összekösse.

Minőség, tesztelés és biztonság

A minőséget itt nem a látvány dönti el. Egy belépési gomb lehet szép, mégis rosszul működhet. A valódi minőség az, hogy a felhasználó több eszközről is be tud lépni, a hibák érthetően jelennek meg, a fiókok nem duplázódnak, és az adatok nem kerülnek rossz helyre. A tesztelésnek ki kell terjednie új felhasználóra, meglévő felhasználóra, visszavont engedélyre, hibás e-mail adatra és sikertelen belépésre is.

Én azt látom, hogy a jó fejlesztő nem csak elkészíti a funkciót, hanem megmutatja, hogyan lehet ellenőrizni. Készít egy rövid listát a tesztlépésekről, és jelzi, ha valamelyik szolgáltatónál további jóváhagyás vagy ellenőrzés kell. Ez különösen fontos akkor, ha a belépés nem csak weboldalon, hanem alkalmazásban is működik.

A biztonság miatt a hozzáférések átadását is érdemes átgondolni. Nem jó megoldás, ha minden jelszó üzenetben vándorol. Jobb ideiglenes hozzáférést adni, majd a munka végén visszavonni vagy módosítani. A kész munka átadásakor a megrendelőnek tudnia kell, melyik szolgáltatói fiókban vannak az alkalmazásbeállítások, hol lehet kulcsot cserélni, és ki fér hozzá ezekhez. Ez száraz résznek tűnik, de egy későbbi hiba esetén sok időt takarít meg.

A Beépített bejelentkezés akkor ad valódi értéket, ha egyszerűbbé teszi a felhasználó belépését, miközben a háttérben rendezett marad a fiókkezelés. Egy magánszakemberrel végzett online munka erre jó megoldás lehet, ha a feladat pontos, a hozzáférések tiszták, és a végeredmény nem csak működik, hanem átadható és ellenőrizhető is.