Kirjoitin viisi vuotta sitten artikkelin, johon kokosin vinkkejä siitä, kuinka palveluiden rekisteröityminen ja sisäänkirjautuminen kannattaisi hoitaa niin, ettei konversio kärsi eikä käyttäjiä suututa. Artikkeli on valitettavan ajankohtainen edelleen. Monet siinä mainitut käyttöliittymäongelmat ovat yhä riesanamme.

Tällä alalla on sittemmin tapahtunut monenlaista, ja olen itsekin oppinut lisää. Koostin tähän artikkeliin ajankohtaista tietoa helposta tunnistautumisesta. Teksti perustuu Alma Talentin Tivi tunnistautuminen 2020 -tapahtumassa pari viikkoa sitten pitämääni esitykseen.

Tämä on pitkä teksti, kuinkas muuten. Se koostuu neljästä osasta:

1. Miksi tällä on väliä?
2. Kuinka vältät salasanahölmöydet?
3. Salasanoja paremmat ratkaisut
4. Mahdollisimman siedettävä vahva tunnistautuminen

Oma salainen tunnistautumishistoriani

Mikä minä olen kirjoittamaan koko aiheesta? Olen päässyt vuosien varrella olemaan mukana useammassa projektissa, joissa helppo tunnistautuminen on ymmärretty ottaa tosissaan. Sen myötä olen alkanut pitää mekkalaa aiheesta aina kun mahdollista.

Olen päässyt olemaan mukana monissa projekteissa, joissa helppo tunnistautuminen on ymmärretty ottaa tosissaan.

Aikoinaan Elisalla työskennellessäni toimin Elisa Kirja -palvelun suunnittelijana ja olin mukana miettimässä, kuinka käyttäjä voidaan tunnistaa e-kirjanlukijan SIM-kortin perusteella niin, että laitteen voi ottaa käyttöön heti ilman erillistä sisäänkirjautumista. Kiinnitimme tuolloin erityistä huomiota myös verkkopalvelun käyttöönottoprosessiin – ehkä kerron siitä joskus tarkemmin.

Elisalla toimin myös suunnittelijana tiimissä, joka määritteli, kuinka operaattoreiden yhteinen Mobiilivarmenne toimii. Pääsin määrittämään monia käyttöliittymätekstejä, joiden piti toimia tekstiviestiformaatin merkkimäärissä. Suunnittelin myös referenssitoteutuksen mobiilivarmenteen web-kirjautumisnäkymille.

Qvik-aikana olen päässyt suunnitelemaan erilaisia laitepohjaisia tunnistusratkaisuja. Kerran pääsin suunnittelemaan ratkaisun, jossa käyttäjä pystyi tunnistautumaan sykesensorin avulla ja kirjautumaan helposti ryhmäliikuntatunnille.

Ylen Uutisvahtia tehdessämme opin ensin, että kirjautuminen ei ole personoidun kokemuksen edellytys. Kun tuotteeseen lopulta toteutettiin kirjautuminen, pääsin suunnittelemaan kirjautumispolun, jossa olisi kerrankin huomioitu kaikki edellisen artikkelini mainitsemat ongelmakohdat (sittemmin toteutus on vaihdettu).

Tallinkille suunnittelimme kertakirjautumisratkaisun, jolla käyttäjä pääsee kiinni matkansa tietoihin tietämättä hankalia asioita, kuten käyttäjätunnuksia, salasanoja ja varausnumeroita.

Sittemmin olen päässyt kommentoimaan myös uuden sukupolven mobiilivarmenteen suunnitelmia.

1. Miksi tällä on väliä?

Tunnistautuminen liittyy kolmeen liiketoimintakriittiseen vaiheeseen:

1. Ensimmäinen käyttökerta
2. Palaava käyttö
3. Maksaminen

Mikä tahansa palvelu hyötyy siitä, että nämä asiat ovat kunnossa. Tunnistautuminen koskee palvelun jokaikistä käyttäjää. Silti aihepiiriin ei panosteta lainkaan niin paljon kuin pitäisi.

Koetaan ehkä, että kyseessä on triviaali, ratkaistu ongelma. Piirretään siihen jokin kirjautumisnäkymä ja siinä se. Ajatellaan ehkä, että kyseessä on regulatorinen tai tekninen kysymys. Ei niinkään kiinnostava liiketoiminnan tai designin kannalta.

Yksi harha on siinäkin, että kuvitellaan, että asiakkaat ovat erityisen kiinnostuneita juuri tästä palvelusta. Itsellähän se on aina mielessä, kun sen parissa päivittäin tekee töitä, mutta joillain toimialoilla asiakkaat saattavat käydä palvelussa kerran tai pari vuodessa.

Esimerkiksi matkailualalla (muistatteko vielä sellaista?) käyttöfrekvenssi on tyypillisellä asiakkaalla varsin harva. Lopputulos voi näyttää tältä.

(Nykyään en oikein uskalla valittaa enää mistään julkisesti, kun joka oksalla saattaa istua tuleva tai nykyinen asiakas – tai tuleva entinen – mutta nämä palvelut ovat sittemmin uusiutuneet, niin uskallan käyttää näitä esimerkkinä).

Kirjautumiseen käytetään ylimääräistä käyttäjätunnusta ja koska käyttäjät eivät muista niitä, tarjolla on erikseen toiminto niiden palauttamista varten.

Ei riitä, että kirjautuu. Vielä pitäisi kaivaa jostain hankala varaustunnus ennen kuin saa matkansa nähdäkseen.

VR:n vanhalla sivulla oli myös käytössä erillinen käyttäjätunnus, joka piti muistaa ja johon liittyi muotovaatimuksia. Salasanakaan ei tainnut huolia erikoismerkkejä, vaikka sitä ei tässä kerrotakaan.

Uusien käyttäjien aktivoimisen ja palaavan käytön helpottamisen lisäksi tunnistautuminen korostuu nykyään yhä enemmän myös maksamisessa. PSD2-direktiivin seurauksena maksutapahtuman yhteydessä joutuu yhä useammin tunnistautumaan vahvasti (ns. SCA, strong customer authentication).

Tässä vaiheessa huono kokemus näkyy nopeasti menetettynä kauppana.

(On oma lukunsa, kuinka tunnistaumistarvetta voidaan välttää maksamisen yhteydessä. Olen saarnannut tästä erilaisissa tapahtumissa viime vuosina, mutta pitääpä kirjoittaa joskus myös. Tämä taitaa olla ainoa tekstini aiheesta. )

Tunnistautuminen liittyy kolmeen palvelun käytön avainhetkeen

2. Kuinka vältät salasanahölmöydet?

Kaikkein helpoin kirjautumiskokemus on sellainen, jota ei tarvitse tehdä lainkaan. Ihan ensimmäiseksi kannattaa miettiä, tarvitseeko palvelu välttämättä kirjautumista vai voisiko alkuun päästä ilmankin.

Ylen Uutisvahdista haluttiin aikoinaan tehdä alusta asti korostuneen henkilökohtainen palvelu. Yle Tunnus -palvelu oli silloin vasta työn alla, joten vaihtoehtoina olisi ollut odottaa vuosi sen valmistumista, rakentaa odotellessa väliaikainen viritys tai selvitä ilman. Valitsimme jälkimmäisen vaihtoehdon. Kullekin laitteelle luotiin taustalla tunnus, johon personointi sidottiin. Palvelu ehti kerätä satoja tuhansia käyttäjiä ennen kuin Yle Tunnus valmistui ja kirjautumistoiminto lisättiin mukaan.

Erilaisilla evästeillä voi usein tunnistaa käyttäjiä yllättävänkin tarkasti. Saattaa käydä niin, että palvelun puolesta tiedämme, kuka käyttäjä on, mutta hän mieltää uloskirjautuneena olevansa tunnistamaton, joten voisi tuntua oudolta personoida palvelua liian paljoa.

Matkailuala tarjoaa esimerkin. Todella monen palvelun etusivu näyttää aina samalta. Se on suunnattu tuntemattomalle asiakkaalle, jolla ei ole matkaa varattuna. Joskus saatetaan olla fiksuja ja muokata etusivu erilaiseksi kirjautuneelle käyttäjälle, jolla joko on tai ei ole varattua matkaa.

Jännäksi tilanne menee silloin, kun vaikka tiedämme, minne asiakas on varannut matkan, mutta hän ei ole kirjautunut sisään. Silloin voisi tuntua oudolta tarjota liian täsmästi tähän matkaan liittyvää lisämyyntiä.

Yksi vaihtoehto siinä tapauksessa on ainakin korostaa kirjautumistoimintoa ja kertoa, että matkan hallinta käy helposti kirjautumisen jälkeen.

Teknologia saattaa mahdollistaa personoinnin tunnistetulle, kirjautumattomalle käyttäjälle, mutta liika personointi voi tuntua ahdistavalta.

Danske-pankki toimii tähän tapaan. Palvelun etusivun sisältö vaihtuu sen perusteella, onko käyttäjä tunnistettu vai ei. Tunnistetulle käyttäjälle avataan valmiiksi kirjautumisosio rohkaisemaan sisäänkirjautumista ja sisältö vaikuttaa olevan erilaista kuin tuntemattomalla käyttäjällä.

Danske personoi sisältöä kirjautumattomalle, tunnistetulle käyttäjälle

Sisällön personointi tosin ei kuulemma toimi kovin hyvin. Kuvakaappauksen ottanut kaverini kertoi, että hän koki tunnistamattomana saamansa sisällön kiinnostavammaksi kuin hänelle tarkoitetun. Hänellä on jo Apple Pay käytössä, niin miksi sitä vielä mainostetaan.

(Noin, ei tarvitse Danskellekaan sitten tehdä hommia. Palakaa, sillat!)

Vähän samaan tapaan Nordean sovellus mainostaa minulle yhä uudestaan ASP-lainaa, vaikka olen nostanut sellaisen heiltä jo vuosia sitten.

[Kun kaikki menee ja sillat on poltettu, et pääse enää edes sinne alle nukkumaan, muistathan?]

• 

Trivago näyttää kirjautumattomalle käyttäjälle listauksen aiemmista hauista evästeen perusteella

Kaikenlaista voidaan tehdä ilman kirjautumistakin, mutta joskus sen aika kuitenkin tulee. Apple tarjoaa Sign in with Apple -tyyliohjesivuillaan muutamia yleispäteviä ohjeita kirjautumisen toteutukseen:

• Jos pyydät ihmisiä kirjautumaan, tarjoa vastavuoroisesti arvoa
• Lykkää kirjautumista niin pitkälle kuin suinkin mahdollista
• Verkkokauppasovelluksessa anna käyttäjän tehdä ostos ennen kuin pyydät tätä kirjautumaan sisään
• Selitä kirjautumisesta saatavat hyödyt

Jätetään lukijan harjoitukseksi pohtia, kuinka moni suoraan tylyyn kirjautumisnäkymään aukeava sovellus rikkoo näitä ohjeita.

(En uskalla suututtaa enempää tahoja, mutta näitä esimerkkejä ei ole vaikea löytää.)

Jos käyttäjä on kirjautunut jo yhdessä kanavassa, on kohteliasta kirjata hänet sisään seuraavassa. Kun yritin aikoinaan saada Tallinkilla läpi ajatusta, että heidän olisi hyvä tehdä mobiilisovellus verkkopalveluiden rinnalle, yksi tuoteomistajan asettama vaatimus oli, että jos käyttäjä on ostanut matkan selaimessa tai kirjautunut sisään, sovelluksen pitää asennuksen jälkeen osata hakea matka sovellukseen automaattisesti ja tarvittaessa kirjata käyttäjä sisälle.

– Tuo ei ole mahdollista. App Storen lävitse ei voi välittää parametreja webistä sovellukseen ja Google Playssäkin tämä on rajallista, sanoin.
– Make it happen, tuoteomistaja vastasi.

(Tuolloin ajattelin vielä, että on hyvä idea tuoda asiantuntemustaan esiin kertomalla, miksi jokin on vaikeaa.)

Näin löysin asian nimeltä deferred deep linking. Kolmansien osapuolten ratkaisuilla on mahdollista välittää tietoja niin, että asennettu sovellus saa ne tietääkseen ensimmäisellä käynnistyskerralla ja osaa reagoida näihin. Tällaisia palveluita ovat mm. Branch ja sittemmin myös Google Firebase. Kovin tunnettu tämä mahdollisuus ei ole vieläkään, vaan monet palvelut kohtevat asennuslinkistä saapunutta käyttäjää kuin muukalaista.

• 

Jos käyttäjä ostaa verkossa kirjautuneena matkan, varausvahvistussivu on hyvä paikka mainostaa sovellusta. Kun sovellus on asennettu, on huomaavaista kirjata käyttäjä sisään ja noutaa varattu matka automaattisesti. Edelleen tuntuu, että harva edes tietää, että näin voi tehdä. Taikasana on ”deferred deep linking”. (Voipa olla, että tuo reissu ei kyllä toteudu.)

Nyt viimein ne salasanahölmöydet. Edellinen artikkelini kertoi niistä ja on enimmäkseen yhä ajantasainen. Kannattaa katsoa myös tämä mainio Twitter-ketju, jossa on muutama artikkelista puuttuva ajatus.

Tämä kuva koostaa muutaman vältettävän asian.

• 

Älä tee näin, jos käytät perinteistä käyttäjätunnukseen ja salasanaan perustuvaa kirjautumista

Kuten sanottua, nämä ovat yhä valitettavan ajankohtaisia ohjeita. Viimeksi tällä viikolla Gigantti ei huolinut salasanaani, sillä siinä oli erikoismerkki.

Tällä tavalla Gigantti kertoo, että salasanoissa ei saa olla erikoismerkkejä

3. Salasanoja paremmat ratkaisut

On monia salasanoja parempia tapoja tunnistaa käyttäjiä. Osa toimii yksinään, osa ratkaisun osana. Moni on salasanaa työläämpi toteuttaa, mutta käyttäjälle kätevämpi. Tämä Smashing Magazinen koosteartikkelikin on jo neljä vuotta vanha, mutta yhä mainio katsaus aiheeseen.

Seuraavassa on muutama täsmäkommentti eri ratkaisuista.

• 

Salasanoille on paljon vaihtoehtoja (Lähde: Smashing Magazine)

Kertakäyttösalasana tekstiviestillä

Yksi yleiseksi käynyt ratkaisu on kertakäyttösalasanan lähettäminen tekstiviestillä. Tämä ei ole tarkkaan ottaen kovin tietoturvallista, mutta riittää moniin harmittomiin palveluihin. Hyvässä toteutuksessa on minimoitu kaksi asiaa:

• Käyttäjän puhelinnumeron syöttämisen vaiva
• Tekstiviestin mukana tulevan koodin syöttämisen vaiva

Androidilla se näyttää tältä: puhelinnumeron voi valita valikosta, joka listaa sovelluksen löytämät puhelinnumerot. Tuohon ei voi ikävä kyllä täysin luottaa, vaan joskus sen joutuu silti kirjoittamaan käsin.

Kun palvelin konfiguroidaan oikein, sovellus voi lukea tekstiviestissä olevan koodin ja syöttää sen suoraan sovellukseen, jolloin käyttäjä säästyy koodin opettelemiselta ulkoa tai hankalasta viestisovelluksessa edestakaisin hyppimiseltä.

• 

Näin hoidetaan Androidilla mahdollisimman helppo tunnistautumiskokemus kertakäyttösalasanalla. Se näyttää monimutkaiselta, mutta oikeasti siinä ei tehdä muuta kuin valitaan, että puhelinnumero on oikein ja odotetaan hetki. Lähde ja ohjeet

Takavuosina tämä taikatemppu vaati lupia puhelimen käyttämiseen ja tekstiviestien lähettämiseen käyttäjän nimissä. Nämä olivat niin vaarallisia pyyntöjä, että hyvää tarkoittava oikotie muuttuikin pelottavaksi ja hankalaksi. Nykyään tämä onnistuu onneksi ilman.

Jos palvelinpäätä ei ole mahdollista syystä tai toisesta laittaa pystyyn koodin automaattiseksi lukemiseksi, käyttäjän elämää voi silti helpottaa muotoilemalla tekstiviestin oikein. Jos käyttäjällä on SMS-sovelluksenaan Google Messages ja viesti on oikein muotoiltu, ilmoitusviestiin ilmestyy automaattisesti Kopioi-painike, jolla kertakäyttösalasanan voi kopioida helposti.

Tässä kohtaa on syytä huomioda, ettei oman sovelluksen koodikenttää ole kikkailtu niin, ettei siihen voi liittää koodeja leikepöydältä. Tämäkin hölmöily on surullisen yleistä, jos käyttöliittymämäärittely on tehty vain kuvina eikä kukaan ole testannut sitä läpi.

Kopiointipainikkeella säästää säätämistä. Lähde: The Verge

Hankaluus on, että Messages on nirso viestin muotoilusta eikä toimivaa syntaksia ole ilmeisesti dokumentoitu missään.

Kollegani tutki jopa Messages-sovelluksen lähdekoodia, mutta ei löytänyt tätä käsittelyä sielä. Testasin aikoinaan, että tällä viestillä kopiontipainike ei ilmesty ”364309 is your Tallink & Silja Line activation code.” Ajattelin, että syy olisi &-merkissä, mutta sen poistaminen ei auttanut. Viestiä lyhentämällä kopiointinappi viimein ilmestyi näkyviin: ”364309 is your Tallink activation code.” olisi toiminut.

iOS-puolella mahdollisuudet ovat hieman rajallisemmat. Puhelinnumeroa ei voida kysyä järjestelmältä, mutta oikein määritetyn tekstikentän kanssa iOS 13:n näppäimistö osaa tarjota yhden painalluksen oikotien puhelinnumerolle.

Helppo puhelinnumeron syöttö iOS:llä. Lähde

Vastaavasti kertakäyttösalasanaa ei voida lukea taustalla, mutta sekin saadaan yhden painalluksen päähän.

Kertakäyttösalasanan poimiminen viestistä melkein automaattisesti. Lähde

Nykyään on varmasti paljon sovelluksia, jotka tekevät tämän hyvin molemmilla alustoilla. Olen vanhastaan kehottanut katsoamaan mallia Lyftistä.

Taikalinkillä eroon salasanoista

Takavuosina Tallinkin kirjautuminen oli toteutettu hankalasti. Käyttäjän piti keksiä erillinen käyttäjätunnus, joka ei voinut olla muodoltaan sähköpostiosoite. Lisäksi jos salasanan unohti, järjestelmä loi aina uuden salasanan, jota käyttäjä ei oppinut ulkoa ja harvoin jaksoi käydä vaihtamassakaan. Lopputuloksena Salasana unohtui oli yksi sivuston käytetyimpiä sivuja.

Kun uutta ratkaisua lähdettiin tekemään (edellä mainitun) tuoteomistajan tehtävänanto oli yksinkertainen:

– Mitä ikinä teettekin, hankkiutukaa eroon käyttäjätunnuksista ja salasanoista, hän sanoi.
– I’m gonna make it happen, vastasin.

(Olin jo oppinut olemaan.)

Lopputuloksena tehtiin fiksu tekstikenttä, johon saisi kirjoittaa mitä vain sattuu tietämään itsestään. Puhelinnumero, sähköpostiosoite, kanta-asiakaskortin numero – kaikki käy. Järjestelmä sitten yrittäisi selvittää näiden perusteella kenestä on kyse ja kysyisi tarvittaessa lisäkysymyksiä ja lähettäisi lopulta kirjautumislinkin joko sähköpostilla tai tekstiviestillä.

Tekstikenttä muuttaa muotoaan sen mukaan mitä siihen kirjoitetaan.

Periaatteeltaan ratkaisu on toimiva mihin tahansa palveluun, joka ei vaadi vahvaa tunnistautumista.

(Jätetään lukijan harjoitukseksi tunnistaa mitä ongelmia nykytoteutuksessa on.)

Olen saanut luvan esitellä tuloksiakin. Julkaisun jälkeen vierailut Salasana unohtui -sivulla loppuivat kuin seinään.

Vierailut Salasana unohtui -sivulla uuden kirjautumispalvelun julkaisua ennen ja sen jälkeen.

Kolmansien osapuolien kirjautumispalvelut

Facebook-kirjautuminen on ollut yleinen vaihtoehto salasanoille jo vuosikymmenen ajan. Yleisemmin kolmansien osapuolten kirjautumispalveluihin tavataan viitata sanalla social login, vaikka välttämättä palvelut eivät edustakaan sosiaalisia verkostoja.

Palveluista on hyötyä sekä käyttäjille että palveluntarjoajille:

Etenkin erikoistilanteissa kirjautumispalveluista voi olla paljon apua. Ammattitiedot saa täytettyä Linkedinin perusteella kätevästi ilmoittautuessaan tapahtumaan.

Huonot puolet ovat ilmeisiä. Datan hallinta on epämääräistä ja käyttäjä saattaa päätyä kertomaan itsestään enemmän kuin haluaisi. Myös kalvavalla epävarmuudella on hintansa. Usein kirjautumispalvelut on myös integroitu sikäli hankalasti, että käyttäjän pitää sisään kirjautuessaan muistaa, minkä palvelun kautta aikoinaan rekisteröityi.

Google on pitkään tarjonnut omaa kirjautumispalveluaan, ja se on Android-käyttäjille luonteva vaihtoehto. Käyttäjä on joka tapauksessa kirjautunut Google-tililleen puhelimessa, joten ylimääräistä säätämistä ei tarvita. Googlen maine tietosuojan kannalta on myös näppituntumalla hieman Facebookia parempi.

Tähän saakka iOS-puolen tilanne on ollut epäselvempi. Aikoinaan Twitter oli Applen erikoissuosiossa, sillä Twitter-kirjautuminen oli ensimmäinen kolmannen osapuolen kirjautumismahdolisuus, joka tuotiin iOS:ssa järjestelmätasolle versiossa 5.

[Sinäkö ihan oikeasti ajattelet, että on siistiä päteä muistavansa jotain tällaista?]

Sittemmin myös Facebook-kirjatuminen tuotiin järjestelmätasolle, mutta Apple oli samaan aikaan oudon mustasukkainen Facebookin käyttämisestä kirjautumiseen. Applella oli epämääräinen sääntö, että Facebook-integraatiota ei saa tuoda sovellukseen vain helpottaakseen kirjautumista, vaan Facebookin avulla pitää tarjota käyttäjälle jotain muutakin lisäarvoa. Muistan itsekin kerran suunnitelleeni yhden startupin sovellukseen jotain väkinäistä Facebook-pohjaista Kutsu kavereita -toimintoa vain, jotta kirjautumismalli saatiin Applelta läpi. Facebookia oli pakko käyttää sovelluksessa, sillä verkkopalvelukin oli rakennettu Facebook-kirjautumisen varaan.

Nykyään Applella on parempi syy mustasukkaisuuteen: viime vuonna julkaistiin viimein Applen oma kirjautumisratkaisu Sign in with Apple. Siitä on hyvä huomata kaksi asiaa:

• Sitä on pakko tukea, jos haluaa käyttää sovelluksessaan jotain muuta kolmannen osapuolen kirjautumispalvelua (siirtymäaika päättyy 30.6.)
• Se tarjoaa käyttäjälle mahdollisuuden käyttää tekaistua sähköpostiosoitetta. Palveluntarjoaja voi luottaa, että osoite toimii mutta osoitetta ei voi käyttää käyttäjän tunnistamiseen toisessa kanavassa, sillä käyttäjä ei aktiivisesti tiedä, mikä sähköpostiosoite hänestä välittyy.

Jos ymmärrän oikein Applen linjauksen vaikutukset, näyttäisi siltä, että jos haluaa tukea iOS-sovelluksessaan esim. Facebook-kirjautumista, täytyy rakentaa Sign in with Apple -tuki kaikkiin kanaviin 30.6. mennessä. Siihen nähden tästä puhutaan aika vähän!

Sign in with Apple tarjoaa palveluntarjoajalle minimaalisen vähän tietoa. Se välittää eteenpäin nimen, mahdollisesti tekaistun sähköpostin sekä uniikin tunnisteen. Toisin kuin Apple Pay, se ei välitä myöskään käyttäjän osoitetietoja.

Sign in with Apple mahdollistaa tunnistautumisen sormenjäljellä tai naamaa näyttämällä. Lähde: Macstories.

Hyvä puoli siinä on, että se tukee biometrista tunnistautumista, eli sormenjälki tai naaman näyttäminen riittää. (Kaipaisin muuten biometriselle suomenkielistä ja helppotajuista vastinetta.) Google ei ole saanut jostain syystä laajasti käyttöön vastaavaa Google Sign-in -palveluun, vaikka se muuten toimiikin kätevästi.

Kotimaiset vaihtoehdot

Oma lukunsa ovat paikalliset tunnistautumispalvelut. Yle viesti aikoinaan tarkoituksekseen tehdä Yle Tunnuksesta yleispätevä kotimainen vaihtoehto ylikansallisille ratkaisuille. Tässä hengessä Uutisvahdistakin poistettiin siellä hetken aikaa ollut Facebook-kirjautumisvaihtoehto. Nykyään Yle Tunnuksen sivuilla mainitaan ainoaksi ulkopuoliseksi käyttökohteeksi Helsingin kaupungin Varaamo-palvelu.

Uusi haastaja saattaa tulla teleoperaattorimaailmasta. Operaattorit ovat kertoneet työstävänsä mobiilivarmenteen uutta sukupolvea. Siinä missä edellinen versio majaili puhelimen SIM-kortilla ja vaati tämän vuoksi erityistä aktivointia, uudesta versiosta tulee sovelluspohjainen. Sen voi olettaa toimivan pitkälti samaan tapaan kuin pankkien tunnistussovellusten.

Vanha tekstini kertoo, kuinka mobiilivarmenne toimii.

Operaattorit ovat lisäksi kertoneet, että nykyisen vahvan tunnistautumisen lisäksi uusi mobiilivarmenne tarjoaa myös heikomman turvatason, joka kilpailee suoraan Facebookin, Googlen ja Applen tunnistusratkaisujen kanssa.

Vaikka tältä vaihtoehdolta puuttuu käyttöjärjestelmätason integraatio, operaattoreilla on vahva markkina-asema, joten jos tämä hinnoitellaan ja toteutetaan oikein, on helppo povata tälle menestystä. Kirjoitan kohta vielä vähän lisää mobiilivarmenteesta vahvan tunnistautumisen yhteydessä.

SisuID on vastaavasti kotimainen vahvan tunnistautumisen riippumaton ratkaisu, mutta sen nykytilanne on minulle hieman epäselvä.

4. Mahdollisimman siedettävä vahva tunnistautuminen

Voi, minä vihaan vahvaa tunnistautumista. Se toimi aikoinaan huonosti työpöytäselaimissa ja sittemmin vielä huonommin mobiiliselaimissa. Nykyään tilanne on jo vähähän parempi, mutta ei se ole vieläkään yhtään niin helppoa kuin pitäisi.

Jos aihetta haluaa tutkia, jargon-lyhenne on SCA (strong customer authentication). Tällaisia asioita on meneillään:

Miltä näyttää sujuva vahva tunnistautuminen?

Eri pankkien toteutukset vaihtelevat. Seuraava kuva esittää prosessin eri vaiheita ja niihin liittyviä onnistumisen edellytyksiä.

• 

Tunnistautumispolun eri vaiheet voidaan toteuttaa helpommin tai hankalammin

Ensin käyttäjä kertoo verkkopalvelussa jotenkin, kuka on. Tässä voidaan käyttää pankkisovellusten tapaan salaista käyttäjätunnusta, joka täytyy opetella ulkoa. Hankalimmillaan tämän lisäksi tarvitaan erillinen salasana. Mobiilivarmenteessa käytetään puhelinnumeroa, joka on helppo muistaa, mutta jonka muutkin tietävät ja voivat näin lähettää tunnistuspyyntöjä.

Oma kysymyksensä on, voisiko tämän tallentaa, jos laite on tuttu. Tai esitäyttää, jos ollaan vaikka vahvistamassa luottokorttimaksua, jolloin kortin liikkeellelaskija tietää, kenen kortista on kysymys.

Seuraava vaihe on siirtyminen vahvistussovellukseen. Jos käytetään pelkkää mobiililaitetta, olisi suotavaa hypätä sovellukseen automaattisesti. Jos ollaan tunnistautumassa tietokoneella, puhelimeen olisi kiva saada tunnistautumispyyntö ilmoituksena, jotta tunnistautumissovellusta ei joudu kaivamaan auki käsin. Tähän liittyy yllä mainittu kalastelun uhka, mutta vähintäänkin tunnetuilla laitteilla tämän olisi syyytä toimia.

Seuraavaksi edessä on autentikointivaihe. Tässä nousee esiin kysymyksiä, kuten onko mahdollista käyttää biometrista tunnistusta vai pitääkö naputtaa pin-koodi. Toinen kysymys on, kuinka monta turhaa lisäruutua täytyy katsoa läpi.

Seuraava kysymys on, osaako palvelu linkittää takaisin alkuperäiseen sovellukseen vai pitääkö tämä siirtymä tehdä käsin.

Danske

Dansken suoritus näyttää tältä. Askeleita on peräti seitsemän, käyttäjätunnuksen lisäksi pitää kirjoittaa salasana, sovellusvaihdokset täytyy tehdä käsin. Palaute sovelluskaupoissa korreloi hyvin prosessin hankaluuden kanssa. (Kuvat ovat kollegani ottamia viime syksyltä. Voi olla, että tilanne on nykyään parempi.)

• 

Dansken toteutuksessa askeleita riittää

Nordea

Nordean versio on paljon suoraviivaisempi. Siinä mietityttää oikeastaan ainoastaan yksi ylimääräinen askel ennen kuin hypätään tunnistautumissovellukseen. Myöskään käyttäjätunnusta ei saa pysymään selaimen muistissa vaikka haluaisi.

• 

Nordean toteutus on merkittävästi Danskea yksinkertaisempi, kunhan biometrisen tunnistuksen huomaa kytkeä päälle ja palveluntarjoaja tukee uutta mobiilitoteutusta

Nordeasssa on hämmentävää, että uusi mobiilioptimoitu toteutus tulee tarjolle vain joskus. Välillä päätyy tekemisiin vanhan työpöytäversion kanssa, jossa joutuu hyppimään vaikeasti edestakaisin selaimen ja koodisovelluksen välillä ja jostain syystä tunnistautumaan kahdesti maksua vahvistaessaan. Sen ainoa hyvä puoli on, että se muistaa käyttäjätunnuksen.

• 

• 

• 

• 

• 

Näiden ruutujen lisäksi välissä käydään kaksi kertaa Nordean koodisovelluksessa kirjoittamassa koodi ja välissä vaihdetaan sovellusta käsin edestakaisin

[Muokkaus 18.5. Sain Nordealta tarkennuksen tässä Twitter-ketjussa. Vanhaa polkua käytetään maksamisessa ja uutta tunnistautumisessa. Myös maksamisen polku on uudistumassa pian. Esimerkiksi SPR:n palvelussa on käytössä uusi versio. Hyvä syy käydä lahjoittamassa vähän.]

Lisäksi Nordea koodisovellus piilottaa varsinkin Androidilla tosi hankalaan paikkaan biometrisen tunnistamisen kytkemisen päälle (ei kuvaa, sillä kuvakaappaukset on estetty) eikä lainkaan rohkaise tähän esimerkiksi käyttöönottovaiheessa. Minulle ei ole myöskään vielä selvinnyt logiikka, milloin tapahtuman saa vahvistaa sormenjäljellä ja milloin pitää sittenkin kirjoittaa pin-koodi.

Mobiilivarmenne

Perinteinen mobiilivarmenne pärjää kilpailussa pankkeja vastaan varsin hyvin.

Tunnistustapahtuma perustuu SIM-kortilla majailevaan sovellukseen, jonka kukin laitevalmistaja näyttää omalla tavallaan. Hyvä puoli on, että toteutusteknologian vuoksi tapahtuma aukeaa suoraan kontekstissa, jolloin erillisiä sovellusvaihdoksia ei tarvita.

Toteutuksessa kiusaa neljäs vaihe, jossa kerrotaan, mitä tietoja ollaan välittämässä edelleen palveluntarjoajalle. Jos ei Nordeakaan tarvitse tällaista, tuskin tälle tarvitse omaa vaihetta omistaa.

Ensimmäisen sukupolven mobiilivarmenne pärjää varsin hyvin verrattaessa pankkien ratkaisuihin.

Mikä hassuinta, esimerkin Kanta-palvelu näyttää seuraavaksi samat tiedot uudestaan seuraavassa vaiheessa. Minulle käyttäjänä riittäisi, että ne näkyisivät pikkupränttinä ennen tunnistustapahtuman vahvistamista, mutta enpä olekaan juristi.

Täytyy tässä yhteydessä mainita, että mobiilivarmenteen käyttö on viime vuosina kasvanut yllättän paljon siihen nähden, kuinka vähän sitä on markkinoitu.

Ficomin tilastojen mukaan mobiilivarmenteen käyttö kaksinkertaistui viime vuoden aikana, ja tunnistustapahtumia oli yli 7 miljoonaa kappaletta. Tarkkoja käyttäjämääriä ei ole julkistettu, mutta voidaan olettaa puhuttavan sadoista tuhansista käyttäjistä.

Mobiilivarmenteen käyttö kaksinkertaistui viime vuonna

Monessa palvelussa mobiilivarmenne on suurimpien pankkien jälkeen kolmanneksi suosituin tunnistautumistapa. Syyksi tälle on arveltu erityisesti sitä, että tuki alkaa olla kohdallaan. Se kelpaa melkein kaikkialla paitsi verkkopankeissa.

Pitkälti tähän tiivistyykin ennustus uuden mobiilivarmenteen menestyksestä. Jos vahva tunnistautuminen pysyy maksullisena, kuten nykyisessä versiossa eikä sen avulla edelleenkään pääsee eroon oman pankin tunnistautumisratkaisusta, kuinka moni haluaa maksaa siitä, että kirjautuminen muihin palveluihin on kätevämpää? Vaikea sanoa tässä vaiheessa.

Tässä vaiheessa on hyvä luoda kaihoisa katse länteen ja kysyä klassikkokysymys: ”Entä Ruotsissa?”. Ruotsissa on käytössä pankkien yhteinen mobiililompakko Swish sekä pankkien yhteinen tunnistusratkaisu BankID.

Tällä kokonaisuudella maksaminen ja siihen liittyvä tunnistautuminen käy näin kätevästi. Välissä näytetään naamaa Face ID:lle.

• 

Näin naapurissa

Norjassa Vipss toimii samaan tapaan. Sitä voi käyttää maksamisen lisäksi tunnistautumiseen. Se välittää lisäksi kauppiaalle käyttäjän nimen, sähköpostiosoitteen, puhelinnumeron ja toimitusosoitteen, jotta erillistä rekisteröitymistä ei tarvita.

Videossa tunnistaudutaan peliin norjalaisen Vippsin avulla. Keksin ottaa tämän videolle vasta toisella kerralla, joten tässä ei siksi näy, kuinka Vipps-sovellukseen tunnistauduttiin Face ID:n avulla.

Mitä palveluntarjoaja voi tehdä?

Me emme asu Norjassa ja pankkien palvelut ovat mitä ovat. Mitä palveluntarjoaja voi tehdä asiakkaansa elämää helpottaakseen? Ei paljoa, mutta jotain:

• Minimoi tarve vahvalle tunnistautumiselle
• Pyydä kerralla mahdollisimman paljon tietoa

Esimerkiksi Terveystalon sovellus toimii fiksusti. Ensimmäisellä käyttökerralla käyttäjä tunnistetaan vahvasti. Tämän jälkeen henkilökohtaisiin terveystietoihin pääsee tällä laitteella sormenjälkeä näyttämällä.

(Julkituonti: Tässä taas härskisti kehun asiakkaitamme.)

• 

Terveystalo tekee vahvan tunnistamisen vain kerran

Valitettavan usein näkee myös toisenlaisia toteutuksia. Esimerkiksi Lähitapiolan Elämänturva-sovellus on kiillotettu kuin karamelli, mutta kun sillä yrittää tehdä jotain, käyttäjä heitetään sovelluksesta selaimeen, jossa pitää tunnistautua uudestaan. Sovelluskaupan palautteesta huomaa, etten ole ainoa asiakas, joka ei yhtään tykkää tällaisesta. Ei näitä tietenkään kukaan pahuuttaan tee – varmasti tähänkin on teknisiä syitä olemassa, mutta kokemus on huono.

• 

Elämänturvassa matka katkeaa kesken kaiken

Maksamisen yhteydessä voidaan myös tehdä paljon, jotta käyttäjältä voidaan säästää tunnistaumisen vaiva. Tämä on tosiaan ihan oman artikkelinsa aihe, mutta tämän Stripen katsauksen avulla pääsee alkuun. Tai sitten tämän Adyenin.

Hyödyntämällä PSD2-direktiivin poikkeuksia maksukokemusta voidaan sujuvoittaa. Kuva: Adyen.

Vastaavasti esimerkkinä lisätiedon haalimisesta samalla vaivalla, kun käyttäjä kuitenkin tunnistetaan vahvasti, yksi esimerkki voisi olla oheinen kuvitteellinen verkkokauppaesimerkki. Käyttäjä tunnistautuu vahvasti osamaksua varten ja samalla taustalla tehdään luottotietotarkistus selvitetään toimitusosoite.

Qvikillä toteuttamamme verkkokauppaesimerkki, jossa luottopäätökseen liittyvän tunnistautumisen yhteydessä haetaan käyttäjästä myös osoitetiedot

On luultavaa, että erilaiset tunnistuspalveluntarjoajat alkavat tarjota yhä monipuolisempi lisäpalveluita palveluntarjoajille, sillä pelkän tunnistamisen liiketoiminnallinen arvo hiipuu sääntelyn ja kilpailun myötä. Käyttäjän kannalta tämän voisi ajatella olevan myös hyvä asia, sillä tarjonnan parantuessa käyttäjäkokemuksesta tulee vaivattomampi.

Toivon todella, että viiden vuoden kuluttua pääsisin kiukuttelemaan jostain ihan muusta kuin hankalasta tunnistautumisesta!