Tarvitsetko rakentaa oman todennuksen sovelluksillesi?

Taustaa#

Olen nähnyt monien kehittäjien kysyvän kysymyksiä, kuten "Pitäisikö minun rakentaa oma todennus sovellukselleni?”. Vaikka vastaus ei voi olla yksinkertainen "Kyllä" tai "Ei", haluaisin kirjoittaa artikkelin toteutuksen purkamisesta ja esitellä hyvät ja huonot puolet, jotta voit päättää.

TL;DR On tarpeen löytää olemassa oleva ratkaisu, joka sopii tarpeisiisi, ellei sinulla ole todellista halua täyteen hallintaan tai jos olet vielä oppimassa ohjelmistokehitystä.

Johdanto#

Kehittäjänä olen rakentanut monia sovelluksia urani aikana. Ohjelmointikielestä riippumatta on yhteinen perusta, jonka minun on aina rakennettava: käyttäjän todennus.

Se oli mitätön osa, koska kaikki oli yksinkertaista 20 vuotta sitten:

• Toteuta rekisteröinti- ja kirjautumisjärjestelmä käyttäjätunnuksella ja salasanalla.
• Luo mekanismi käyttäjän istunnon ylläpitämiseksi.
• Turvallisuus? MD5 on vastaus.

Siinä se. Sitten voisin keskittyä "varsinaiseen liiketoimintaan". Etkö ole kuullut MD5:stä? Olet jäänyt paitsi ohjelmistokehityksen "hyvistä ajoista". Nykyään kehittäjät kohtaavat enemmän haasteita rakennettaessa kirjautumis-/rekisteröitymistoimintoja.

Se kuulostaa hälyttävältä, mutta käydään asia läpi esimerkin avulla.

Esimerkki: Verkkokirjakauppa#

Sanotaan, että yrität rakentaa verkkokirjakauppaa API-palvelun ja verkkokäyttöliittymän kanssa.

Ensinnäkin "todennuksen" laajuus tulisi määritellä. Todennus voidaan selittää autentikoinnilla ja autorisoinnilla, ja niillä on täysin erilaiset määritelmät ja käyttötapaukset:

Kirjoitin artikkelin CIAM 101: Autentikointi, Identiteetti, SSO käsitelläkseni näitä käsitteitä yksityiskohtaisesti.

Valitse autentikointimenetelmät#

Aloitetaan “autentikoinnilla”, joka on käyttäjän kirjautuminen esimerkissämme. Käyttäjätunnus ja salasana -menetelmän lisäksi tässä on joitain nykyisiä tapoja, joita ihmiset ottavat käyttöön paremman käyttäjämuunnoksen ja turvallisuuden takaamiseksi:

• Salasanaton, eli dynaaminen vahvistuskoodi (sähköpostitse tai tekstiviestinä)
• Sosiaalinen kirjautuminen (Google, Facebook, jne.)

Menetelmän valinta riippuu liiketoimintapäätöksestä, kun taas voimme tarkastella teknistä vaivannäköä:

• Salasanattomaan menetelmään tarvitset palveluntarjoajan lähettämään vahvistuskoodeja sähköpostitse tai tekstiviestinä; sitten integroida se API-palvelusi kanssa (uusia API:ita saatetaan tarvita).
• Sosiaalisen kirjautumisen osalta sinun on noudatettava käyttöönotto-ohjeita valitsemasi sosiaalisten identiteettien tarjoajan kanssa. Lisäksi sinun on luotava yhteys kirjakauppasi käyttäjätunnusten ja identiteetin tarjoajan välille.
  • Esimerkiksi, kun käyttäjä kirjautuu sisään Gmail-tilillä [email protected], voit liittää tämän sähköpostiosoitteen kirjakaupan käyttäjään foo. Tämä prosessi auttaa sinua rakentamaan yhtenäisen identiteettijärjestelmän ja antaa käyttäjälle mahdollisuuden muokata tai irrottaa sosiaalinen identiteettinsä tulevaisuudessa.

Kirjautumiskokemuksen suunnittelu ja toteuttaminen#

Kun olet valinnut autentikointimenetelmät, sujuva ja sulava kirjautumiskokemus loppukäyttäjille on seuraava tavoite. Konversio täällä on olennainen mutta ratkaiseva liiketoiminnalle, sillä se on luonnollinen tapa jättää pysyviä asiakastietoja.

Kun työskentelin Airbnb:lle, siellä oli kokonainen tiimi, joka oli omistautunut optimoimaan kirjautumiskokemusta useille alustoille. He tekivät lukuisia A/B-testejä selvittääkseen, mikä yhdistelmä tuotti korkeimman konversioasteen.

Ei ole käytännöllistä tehdä sitä, kun liiketoiminta on vasta alkamassa. Mutta meidän on silti pyrittävä tekemään jokainen osa oikein. Millä alustoilla haluaisit pyörittää kirjakauppaa? Voit aloittaa mobiililaitteesta, verkosta tai molemmista. Tarkka suunnittelu riippuu valitsemistasi autentikointimenetelmistä:

• Käyttäjätunnus ja salasana: Helpoin, vain muutama syöttökenttä ja painike.
• Salasanaton: Anna puhelin/sähköposti, lähetä ja varmista sitten dynaaminen koodi.
• Sosiaalinen kirjautuminen: Lue valitun sosiaalisen identiteetin tarjoajan dokumentaatiot, seuraa visuaalista ohjetta, käsittele uudelleenohjauslogiikkaa ja lopuksi liitä sosiaalinen identiteetti kirjakaupan identiteettiin.

Muita harkittavia asioita parhaan tuloksen saavuttamiseksi:

• Täytyykö sinun yhdistää kirjautumis- ja rekisteröintiprosessi tietylle menetelmälle?
• Tarvitsetko "unohtunut salasana" -virta, jotta asiakkaat voivat nollata salasanansa itsenäisesti?

Jos päätät kehittää natiivisti, työmäärä lähes kaksinkertaistuu yhdelle lisäalustalle.

Turvallisuus ja merkkien vaihto#

Turvallisuus voi olla piilotettu jäävuori. Ole hienoa, jos olet tuttu OpenID Connectin tai OAuth 2.0:n kanssa, sillä niitä käytetään laajalti ja ne ovat taisteluissa testattuja. OpenID Connect on suhteellisen uusi, mutta se on suunniteltu "käyttäjän autentikoinnille", mikä sopii hyvin verkkokirjakauppaan.

Ilman että syvennymme standardien yksityiskohtiin, on vielä joitain harkittavia asioita:

• Mikä salausmenetelmä pitäisi käyttää salasanoille?
• Mikä on standardi autentikoinnin ja autorisoinnin prosessi?
• Kuinka merkkien vaihto toimii (Access Token, Refresh Token, ID Token, jne.)?
• Kuinka allekirjoitusavaimia voidaan käyttää merkkeissä ja kuinka allekirjoitus voidaan avata resurssien suojaamiseksi?
• Kuinka asiakas- ja palvelin hyökkäykset voidaan estää?

Lopulta voit luoda hyvän kirjautumiskokemuksen ja toimittaa sen asiakkaille.

Autorisaatiomalli#

Kirjakauppana sinun on erotettava resurssit asiakkaille ja myyjille. Esimerkiksi asiakkaat voivat selata kaikkia kirjoja, kun taas myyjät voivat hallita myynnissä olevia kirjojaan. Alkuun on ok aloittaa yksinkertaisilla if-else-tarkistuksilla; kuitenkin, kun liiketoiminta kasvaa, saatat tarvita joustavamman mallin, kuten roolipohjaista pääsynhallintaa (RBAC) tai attribuuttipohjaista pääsynhallintaa (ABAC).

Kirjoitin myös artikkelin CIAM 102: Autorisointi & Roolipohjainen pääsynhallinta perusautorisointikäsitteiden ja RBAC-mallin esittelemiseksi.

Tee päätös#

Kuten näet, todennus ei ole "kaikki tai ei mitään" -ongelma, koska siihen liittyy useita teknisiä komponentteja, ja sinulla tai tiimilläsi voi olla eri tekninen asiantuntemus näillä alueilla. On tärkeää pilkkoa se pienempiin osiin, jotta saat paremman käsityksen nykyisestä tilanteesta.

Päätöksen tekemiseksi kysyn itseltäni seuraavat kysymykset:

• Kuinka kiireellinen projekti on?
• Kuinka paljon vaivaa odotan panostavani todennukseen liiketoiminnan sijaan?
• Mikä on käyttäjäkokemuksen, turvallisuuden ja ylläpidettävyyden prioriteetti?
• Mitkä osat tarvitset täyden hallinnan? Kuinka tuttu minun pitäisi tulla niiden kanssa?
• Jos valitsen joitain kehyksiä/r ratkaisuja, ovatko ne riittävän hyviä kustomointiin tai laajennukseen?
• Jos liiketoiminta kasvaa, täytyykö minun ottaa käyttöön uusi autentikointimalli?
• Jos löydän sopivan toimittajan, onko sen käyttö tarpeeksi turvallista? Tarvitsenko vetäytymissuunnitelman, jos toimittajalle sattuu jotain?

Kysymyksien pohjalta löysin kaksi asiaa:

• Luotettavan autentikointijärjestelmän luominen on erittäin monimutkaista.
• Olemassa olevat toimittajat eivät voi täyttää kaikkia välttämättömiä kriteerejä.

Joten päätin aloittaa erityisen projektin (Logto) todennukselle ja omaksua avoimen lähdekoodin yhteisön alusta alkaen.

Toivottavasti tämä artikkeli auttaa.