Kuinka valita identiteetintarjoaja: Insinööritiimin arviointikehys

Suurin osa identiteetintarjoajien vertailusta kertovista artikkeleista on kirjoitettu identiteetintarjoajien itsensä toimesta. Yllättävää, eikö? Ne luettelevat tuotteensa ominaisuudet, ohittavat puutteet ja kutsuvat sitä "objektiiviseksi oppaaksi".

Tämä artikkeli ei ole sellainen.

Olemme käyneet läpi kymmeniä aitoja yritystason arviointipyyntöjä – todellisia taulukoita ja RFP-dokumentteja, joita hankintatiimit lähettävät toimittajille. Kaava toistuu: insinööritiimit painottavat jatkuvasti liian vähän niitä kriteerejä, joilla on eniten merkitystä, ja liikaa niitä, joilla on vähiten.

Tuloksena? Tiimit valitsevat IdP:n demon perusteella, huomaavat kuuden kuukauden päästä että migraatio on painajaismainen, ja aloittavat arvioinnin alusta.

Tässä on arviointikehys, jonka olisimme toivoneet saavamme ennen aloittamista. Se on tehty B2B SaaS -yritysten insinööritiimeille – niille, jotka rakentavat tuotteita, eivät niille, jotka ostavat työvoiman SSO:ta omille työntekijöilleen.

Nopea vastaus: Mikä ratkaisee IdP-valinnan#

Jos selailet nopeasti, tässä lyhyt versio:

1. Protokollien syvyys on tärkeämpää kuin ominaisuuksien määrä. Pelkkä "OAuth2-tuki" ei kerro mitään. Mitkä grant-tyypit? Voitko räätälöidä token-claimit? Voitko itse toimia OIDC-tarjoajana?
2. Migraatiokyky on #1 aliarvostettu kriteeri. Jos et voi siirtää nykyisiä käyttäjiä pakottamatta salasanan vaihtoon, IdP on käyttökelvoton — vaikka kaikki muu näyttäisi hyvältä.
3. Monivuokrauksen täytyy olla natiivi, ei jälkeenpäin lisätty. Jos organisaatiomallien ja vuokralaistason asetusten kanssa joudut kikkoihin, taistelet järjestelmää vastaan ikuisesti.
4. AI-valmius ei ole tulevaisuuden suunnittelua – se on 12 kuukauden vaatimus. Tokenin vaihto, agentin identiteetti, delegoidut luvat. Jos IdP ei tue näitä, olet ensi vuonna taas arvioimassa uudelleen.

Tämä opas käy läpi jokaisen arviointikohdan tarkemmin, konkreettisin kysymyksin ja varoitusmerkein.

Kenelle tämä opas on (ja kenelle ei)#

Tämä on sinulle jos:

• Olet CTO, Engineering VP tai alustasarkkitehti 50–300 hengen B2B SaaS -yrityksessä
• Sinulla on 100 000+ nykyistä käyttäjää etkä voi sallia häiritsevää migraatiota
• Olet siirtymässä yritysasiakkaille, jotka tarvitsevat SSO:ta, organisaatiomallia ja audit-lokeja
• Sinun pitää kirjoittaa tekninen arviointiraportti ja haluat kehyksen, joka ei tule toimittajalta

Tämä EI ole sinulle jos:

• Haet työvoiman IAM-ratkaisua (SSO sisäisiin työkaluihin) — täysin eri ostospäätös
• Olet 500 käyttäjän startupilla ilman yritysasiakkaita — ota se missä paras SDK ja jatka matkaa
• Tarvitset identiteetin todentamista (KYC/KYB) — täysin eri kategoria

Ulottuvuus 1: Protokollaominaisuudet – Ei vain "tukee OAuth2:sta"#

Jokainen IdP markkinoilla kertoo tukevansa OAuth2:ta ja OIDC:tä. Se on lähtötaso. Ongelma piilee syvyydessä.

Grant-tyypit: Mitkä ja miksi ne merkitsevät#

Pakolliset:

• Authorization Code + PKCE — Ainoa flow, jota selaimessa ja mobiilissa pitäisi käyttää. Jos toimittaja suosittelee Implicit flowta, kävele pois. PKCE ei ole valinnainen vaan turvavaade.
• Client Credentials — Palveluiden välinen tunnistautuminen. Taustapalvelun täytyy tunnistautua ilman käyttäjää.
• Refresh Token — Perustoiminto, mutta toteutuksen yksityiskohdat vaihtelevat rajusti. Voitko määrittää rotaation? Vanhenemisen? Voitko poistaa yksittäisen refresh tokenin tuhoamatta koko sessiota?

Yhä kriittisempiä:

• Token Exchange (RFC 8693) — Mahdollistaa AI-agentin tunnistautumisen, käyttäjän puolesta toimimisen ja delegoinnin. Jos puuttuu nyt, kysy etenemissuunnitelmasta. Jos sitä ei ole, varoitusmerkki.

OIDC-tarjoajan kyky#

Useimmat tiimit eivät kysy: Voitko käyttää tätä IdP:tä OIDC-tarjoajana, etkä pelkästään OIDC-kuluttajana?

Miksi tämä on tärkeää: Kun SaaS kasvaa, kumppanit ja asiakkaat voivat haluta käyttää identiteettijärjestelmääsi omiin työkaluihinsa kirjautumista varten. Silloin tulee tukea tokenin myöntämistä, suostumuksen hallintaa ja kolmansien osapuolien rekisteröintiä. Jos IdP vain kuluttaa ulkoisia tarjoajia mutta ei voi toimia itse tarjoajana, törmäät seinään kun federointi ulospäin tarvitaan.

Kysy:

• Onko IdP:llä OpenID Discovery -päätepiste, jota voit white labeloida?
• Voitko rekisteröidä 1st ja 3rd party -sovelluksia eri luottamustasoilla?
• Voivatko 1st party -sovellukset ohittaa consent-ruudun mutta 3rd party -sovellukset eivät?

JWT:n räätälöinti#

Token on sopimus IdP:n ja palveluidesi välillä. Jos et voi sitä räätälöidä, jokaisen palvelun on tehtävä lisä-API-kutsuja ymmärtääkseen, mitä käyttäjä saa tehdä.

Kysy:

• Voitko lisätä mukautettuja claim-ominaisuuksia access- ja ID-tokeneihin?
• Voitko upottaa organisaatiokontekstin (millä vuokralaisella käyttäjä on kirjautuneena) suoraan tokeniin?
• Voitko luoda mukautettuja scopeja, jotka vastaavat sovelluksesi käyttöoikeusmallia?
• Lasketaanko claimit tokenin myöntäessä, vai voivatko ne täyttyä dynaamisesti webhookilla tai skriptillä?

Token, joka sisältää { "org_id": "org_123", "role": "admin", "auth_level": 2 } mahdollistaa API:n middlewarelle käyttöoikeuspäätöksen yhdessä rivissä. Jos token sisältää vain { "sub": "user_456" }, jokainen palvelu joutuu kyselemään IdP:ltä tai tietokannasta lisätietoja. Laajassa mittakaavassa tämä on ero 2 ms ja 200 ms välillä pyyntöä kohti.

Ulottuvuus 2: Autentikointiflowit – Yksityiskohdat, jotka voivat kaataa kaiken#

Jokaisessa IdP:ssä on tuki email/salasana- ja sosiaalikirjautumiselle. Onnittelut, tämä rajasi vaihtoehdot... kaikkiin.

Erot löytyvät yksityiskohdista, joita demoesitykset eivät kata.

Rekisteröitymisflow#

• Automaattinen sisäänkirjautuminen rekisteröinnin jälkeen: Kirjautuuko käyttäjä automaattisesti rekisteröitymisen jälkeen vai näkeekö taas kirjautumissivun? Pakotettu uudelleen kirjautuminen heti rekisteröinnin jälkeen tappaa konversiot. Yllättävän moni IdP tekee tämän väärin.
• Mukautetut rekisteröintikentät: Voitko kerätä roolen, yrityksen nimen tai käyttötarpeen jo rekisteröinnissä? Vai tarvitaanko erillinen onboarding-prosessi jälkeenpäin?
• Progressiivinen profilointi: Voitko kerätä lisätietoja useammassa vaiheessa sen sijaan, että vaatisit kaiken kerralla?

Kirjautumisflow#

• login_hint-tuki: Kun käyttäjä klikkaa linkkiä markkinointisähköpostista, voiko sähköpostiosoite olla valmiiksi täytetty? Kuulostaa triviaalilta, mutta ero on 40% ja 60% konversioiden välillä.
• Organisaatiokohtaiset autentikointikäytännöt: Voiko organisaatio A vaatia SAML-SSO:ta kun taas B käyttää email/salasanaa? Voiko MFA olla pakollinen vain yritysasiakkaille? Jos vuokralaiskohtaiset auth-politiikat vaativat koodimuutoksia konfiguraation sijaan, kehität samaa asiaa aina uudestaan jokaiselle uudelle asiakkaalle.
• Brändäys räätälöinti: Voitko räätälöidä kirjautumiskokemuksen vuokralaiskohtaisesti? Ei vain logo ja värit vaan täysi CSS, oma domain, white label -sähköpostit. "Hosted UI vai oma UI" tulee olla valinta, ei rajoitus.

Mitä useimmat tarkistuslistat unohtavat#

• Hiljainen tunnistautuminen: Kun token vanhenee, voiko sovellus uudistaa sen ilman uudelleenohjausta? Entä jos myös refresh token vanhenee — onko fallback (esim. liukuva sessio iframe:lla)?
• Tilien yhdistäminen: Jos käyttäjä rekisteröityy Googlella ja yrittää sitten kirjautua sähköpostilla — ovatko nämä kaksi tiliä vai yksi? Miten IdP hoitaa yhdistämisen? Jos tämän tekee väärin, saat tuplia tilejä pysyvästi.
• Salasanaton kirjautuminen: Magic linkit, passkeyt, WebAuthn. Ei koska kaikki tarvitsevat heti, vaan koska yritysasiakkaasi kysyvät näitä puolen vuoden sisään.

Ulottuvuus 3: Sessioiden ja tokenien hallinta — syvät vedet#

Tässä pisteessä erotellaan todellisuus demoista. Session ja tokenin hallinta on tylsää kunnes se menee rikki — ja kun menee, kaikki käyttäjäsi kirjataan ulos samanaikaisesti.

Evästeiden turvallisuus#

Ei seksikästä. Täysin kriittistä.

• HttpOnly, Secure, SameSite -attribuutit: Kaikkien pitää olla oikein asetettuina. Jos IdP ei aseta HttpOnly:tä sessioevästeille, se ei ole valmis tuotantokäyttöön.
• Alidomainien tuki: Jos sovellus pyörii osoitteissa app.tuote.com ja API osoitteessa api.tuote.com, voiko sessio kattaa molemmat? Miten?
• Kolmannen osapuolen evästeiden poistuminen: Chrome poistaa nämä käytöstä. Miten IdP hoitaa cross-origin-autentikoinnin ilman 3rd party -evästeitä? Jos vastaus on "työstämme asiaa", ei riitä.

Muista minut ja pysyvät sessiot#

Käyttäjät haluavat pysyä kirjautuneina viikkoja, ei minuutteja. Mutta 180 päivän pysyvä sessio on hyvin erilainen riski kuin 30 minuutin sessio.

Kysy:

• Voitko määrittää session keston erikseen tokenin eliniästä?
• Onko olemassa "muista minut" -valintaa, joka pidentää session mutta pitää tokenin eliniän lyhyenä?
• Voitko pakottaa uudelleen vahvistuksen arkaluonteisiin operaatioihin ilman session katkaisua?

Refresh tokenien turvallisuus#

• Tokenin kierrätys: Kierrättääkö IdP refresh tokens jokaisella käytöllä? (Pitäisi.)
• Salattu säilytys: Ovatko refresh tokens salatussa tallennuksessa?
• Poisto tarkkuus: Voitko poistaa vain yhden laitteen session vaikuttamatta kaikkiin?
• Mukautuva vanheneminen: Eri appsit tarvitsevat eri tokenin eliniät. Voitko säätää tätä per sovellus, ei vain globaalisti?

Ulottuvuus 4: Autorisointimalli – Perus-RBACista eteenpäin#

Roolipohjainen käyttöoikeusmalli on minimi. Jos IdP ei tue RBACia, sitä ei kannata harkita. Mutta B2B SaaSille RBAC yksin ei riitä.

Organisaatioon sidotut oikeudet#

Käyttäjät kuuluvat organisaatioihin. Heidän oikeudet vaihtelevat per organisaatio, eroten alustan oikeuksista.

Sama käyttäjä voi olla admin Org A:ssa ja katsoja Org B:ssä. Jos IdP ei osaa mallintaa tätä natiivisti, päädyt rakentamaan rinnakkaisen lupajärjestelmän — nyt sinulla on kaksi totuuslähdettä.

Kysy:

• Voitko määritellä roolit organisaatiotasolla, ei vain käyttäjätasolla?
• Voi käyttäjä olla eri rooleissa eri organisaatioissa?
• Onko nykyinen organisaatiokonteksti tokenissa, jotta API tietää, minkä orgin dataa palauttaa?

Monitasoinen valtuutus (auth_level)#

Rahoituspalveluissa, terveydenhuollossa jne. — kaikki autentikaatiot eivät ole samanarvoisia.

Kojetaulun katselu? Sessioeväste riittää. Tilisiirto? Tarvitaan tuore MFA vaikka käyttäjä on jo kirjautunut.

Tämä on step-up-authentikointi ja edellyttää, että autentikaatiotaso (auth_level) on tokenjärjestelmän ykkösluokan kansalainen.

Kysy:

• Voiko token kantaa auth_level-claimia, jonka backend tarkistaa?
• Voiko sovellus laukaista step-up-autentikoinnin ilman täyttä uudelleenkirjautumista?
• Onko auth_level-väittämällä oma vanheneminen session rinnalla?

Jos IdP ei tue tätä natiivisti, rakennat koko koneiston itse — juuri sellaista identiteettilogiikkaa, jonka halusit ostaa pois.

Tokenpohjaiset luvat#

Ihannetilanne: API middleware lukee tokenin, näkee käyttäjän orgin, roolin ja auth-tason ja tekee päätöksen ilman ulkoista palvelua.

Todellisuus monessa IdP:ssä: Tokenista näet kuka käyttäjä on, mutta käyttöoikeuksiin tarvitaan erillinen API-kutsu.

Tämä kutsu luo viiveen, riippuvuuden ja lisää mahdollisia vikatilanteita. 1000 pyyntöä sekunnissa – et halua autorisointitsekkiä verkon yli.

Ulottuvuus 5: Migraatio — Kriteeri, joka ratkaisee kaiken#

Harva puhuu tästä: useimmat IdP-arvioinnit kaatuvat siihen, ettei tiimi ymmärrä käyttäjien migraatiota.

Jos sinulla on 100 000+ käyttäjää, migraatio ei ole "nice to have" — se on koko projekti.

Kolme migraatiotapaa (ja mitkä IdP:n pitää tukea)#

1. Bulk import olemassa olevilla salasana-hasheilla

Käyttäjilläsi on salasanat bcrypt/argon2/etc hashattuina. Voiko IdP tuoda nämä hashit ja tarkistaa niillä salasanat?

Jos kyllä: käyttäjät kirjautuvat vanhalla salasanalla, kaikki toimii. Paras mahdollinen tilanne.

Jos ei: Joka käyttäjälle lähtee "Vaihda salasanasi" -sähköposti. Menetät 30–50% käyttäjistä. Tämä ei ole teoriaa – olemme nähneet näin käyvän.

2. Progressiivinen (laiska) migraatio

Sen sijaan, että migraat ajoissa kaikki, siirrät käyttäjät yksi kerrallaan heidän kirjautuessa. Eka login käy vanhassa järjestelmässä, varmistaa salasanan ja luo käyttäjän uuteen IdP:hen. Tämän jälkeen loginit suoraan uuteen.

Turvallisin tapa isoille massoille, mutta IdP:n pitää tukea:

• Mukautettu autentikaatiokoukku, joka kutsuu vanhaa järjestelmää
• Kyky luoda käyttäjiä lennossa loginin yhteydessä
• Seuranta: ketkä on jo siirretty

3. Dual-write (rinnakkainen järjestelmien käyttö)

Transition ajan vanha ja uusi järjestelmä aktiivisia. Kirjoitukset molempiin, luku vähitellen uuteen. Tarjoaa mahdollisuuden palata taakse, mutta lisää kompleksisuutta.

Migraatiovaroitukset#

• "Tuemme CSV-importia" — Vain profiilit, ei salasanat. Joudut tekemään salasanan vaihdot.
• "Meillä on migraatio-opas" — Lue tarkasti. Jos siinä lukee "käyttäjät vaihtavat salasanan", menetät 30–50% käyttäjistä.
• Ei mainintaa hash-yhteensopivuudesta — Jos toimittaja ei mainitse salasanahasheja, heillä ei ole kokemusta suuriin massoihin liittyvästä migraatiosta.

Kysyttävät asiat#

• Mitä salasana-hash-algoritmeja tuette? (bcrypt, argon2, scrypt, PBKDF2, custom...)
• Voimmeko tehdä progressiivisen migraation ensimmäisen loginin yhteydessä?
• Voimmeko seurata migraation edistymistä – montako käyttäjää siirtynyt?
• Mikä on rollback-strategia jos migraatio epäonnistuu?
• Voimmeko pitää session jatkuvana, ettei käyttäjät kirjaudu ulos?

Jos toimittaja ei vastaa näihin vakuuttavasti, heillä ei ole kokemusta. Jatka eteenpäin.

Ulottuvuus 6: Monivuokraus – Natiivi vs. jälkikäteen lisätty#

B2B SaaS tarkoittaa monivuokrausta. Asiakkaasi ovat organisaatioita, joilla on useita käyttäjiä, rooleja ja pääsyoikeuksia. IdP:n täytyy ymmärtää tämä natiivisti.

Mitä "natiivi monivuokraus" tarkoittaa#

• Organisaatio on ykkösluokan entiteetti: Ei mikään custom-kenttä käyttäjäprofiilissa, vaan oma datamalli tunnuksineen, asetuksineen ja jäsenlistoineen.
• Organisaatiokohtaiset autentikointikäytännöt: Org A käyttää SAML-SSO:ta omalla IdP:llään. Org B käyttää email/salasanaa ja pakollista MFA:ta. Org C kirjautuu Google Workspacen kautta. Kaikki tämä UI:n tai API:n kautta, ei koodimuutoksina.
• Organisaation kutsut ja jäsenhallinta: Adminit voivat kutsua jäseniä, jakaa rooleja, poistaa käyttäjiä. IdP hoitaa kutsuflowin, sähköpostivahvistuksen ja roolien jakamisen.
• Organisaatioon pohjautuvat tokenit: Kun käyttäjä toimii organisaation sisällä, token kantaa kyseisen orgin tiedot. API tietää mille orgille data kuuluu.

"Custom metadata" kiertotie#

Jos IdP:llä ei ole natiivia org-mallia, ehdotetaan käyttäjämetadatan käyttöä (user.app_metadata.org_id = "123").

Tämä kaatuu nopeasti:

• Usean orgin jäsenyys vaatii array-hallinnan metadataan
• Ei sisäänrakennettua kutsu-/jäsenprosessia
• Ei org-kohtaisia auth-politiikkoja
• Ei org-sidonnaisia tokeneita — konteksti joudutaan päättelemään muista tiedoista
• Audit-logit eivät tunne organisaatioita

Jos toimittaja sanoo "voit mallintaa organisaatiot metadatalla", se on sama kuin tallentaisit relaatiot JSONiin. Toimii hetken, kunnes ei.

Kysyttävät asiat#

• Onko org-malli natiivi vai rakennettu käyttäjämetadatan päälle?
• Voivatko käyttäjät kuulua useaan organisaatioon yhtä aikaa?
• Voimmeko määrittää eri autentikointivaatimukset per organisaatio?
• Tukeeko järjestelmä natiiveja org-tason rooleja ja oikeuksia?
• Voivatko organisaatioiden adminit hallita jäseniä itsepalveluna?
• Sisältyykö organisaatiokonteksti tokeniin?

Ulottuvuus 7: Tekoälyvalmius — Kriteeri, jota ei vielä osata kysyä#

Vuosi sitten "AI-agentin tunnistautuminen" ei ollut missään arviointilistassa. Nyt, jos rakennat tekoälyominaisuuksia — copilotit, autonomiset agentit, AI-pohjaiset prosessit — IdP:n täytyy tukea uutta identiteettityyppiä: agenttia.

Miksi agentit rikkovat vanhan mallin#

Perinteinen autentikointi tuntee kaksi: käyttäjän ja sovelluksen. OAuth2 on rakennettu tämän varaan.

Tekoälyagentti tuo kolmannen: ei-inhimillisen entiteetin, joka toimii käyttäjän puolesta rajoitetuin oikeuksin, ja tarvitsee oman audit trailin.

• Agentti ei ole käyttäjä — ei salasanaa tai selainistuntoa
• Agentti ei ole koneiden välillä — toimii käyttäjän puolesta
• Agentti tarvitsee rajatut, määräaikaiset oikeudet — ei koko käyttäjän pääsyä

Mitä IdP:n täytyy tukea#

Token Exchange (RFC 8693): Agentti esittää oman tunnuksen + käyttäjän luvituksen, ja saa rajatun tokenin. Token sisältää: kuka (käyttäjä), mikä (agentti), scope (oikeusrajat), milloin (vanheneminen).

Agentti omana client-tyyppinään: Agentin pitää olla oma OAuth2-klientti oman client_id:n kautta, ei api-avaimella tai jaetulla tokenilla toimiva kikkare.

Delegoitujen scopejen hallinta: Käyttäjä voi myöntää agentille vain tietyt oikeudet — esim. luku ilman kirjoitusta.

Audit trail erotus: Logeissa pitää erottaa "käyttäjä teki X" ja "agentti teki X käyttäjän puolesta". Jos tätä ei erottele, epäonnistut auditoinneissa.

MCP (Model Context Protocol) yhteensopivuus#

MCP yleistyy standardina AI-agenttien ja palvelujen välillä. Jos IdP tukee OAuth-pohjaista autentikointia MCP-palvelimille, agentit voivat autentikoitua protokollatasolla ilman API-avaimia.

Kysyttävät asiat#

• Onko tuki OAuth2 Token Exchangelle?
• Voiko agentit mallintaa erillisinä client-tyyppeinä?
• Voivatko tokenit sisältää delegointitiedot (kuka valtuutti agentin, mitkä scopeet)?
• Erotteleeko audit log agentin ja ihmisen toimet?
• Onko MCP-palvelintuki tai OAuth-tuki agenttien ja työkalujen välillä?

Jos toimittaja ei mieti tätä, rakentavat he vuotta 2020 varten. Sinä ajattelet vuotta 2026.

Ulottuvuus 8: Ei-toiminnalliset vaatimukset — Ne, jotka valvottavat öisin#

Ominaisuudet myyvät. Toimintavarmuus ratkaisee uusimisen.

Suorituskyky#

• Autentikointiläpimeno: Kestääkö järjestelmä 100+ auth-pyyntöä sekunnissa huipulla? Entä 1000+?
• Tokenin validoinnin viive: Jos palvelut validoivat JWT:t paikallisesti (niin pitää), tämä on alle millisekunnin. Jos IdP vaatii introspektiokutsuja, mikä on P99-viive?
• Skaalakatto: Kuinka monta MAU:ta sallitaan? Onko todistettua näyttöä tavoitemäärästäsi?

Säädöstenmukaisuus#

• SOC2 Type II: Ei Type I. Type II tarkoittaa auditointia ajan yli. Jos vain Type I, kysy milloin tulee Type II.
• Audit logit: Jokainen autentikaatiotapahtuma, oikeuksien muutos ja admin-toiminto lokitetaan. Voiko logeja viedä SIEMiin? Ovatko lokit muuttumattomia?
• Datan sijainti: Voitko määrätä mihin alueseen käyttäjädata tallentuu? EU-asiakkaille ei ole vaihtoehto.

Luotettavuus#

• Käyttöaika SLA: 99,9% kuulostaa hyvältä, kunnes huomaat sen olevan 8,7 h vuodessa. 99,99% = 52 min. Autentikaatioon — sovelluksen etuoveen — tämä ero merkitsee.
• Failover: Mitä tapahtuu toimittajan kaatuessa? Onko varasysteemiä? Monialue-toteutus?
• Tapaushistoria: Tarkista status-päiväkirja. Ei sitä mitä lupasivat vaan mitä oikeasti tapahtui.

Datan siirrettävyys#

• Käyttäjien vienti: Voiko viedä kaiken, mukaan lukien metadata, jäsenyydet ja roolit? Missä muodossa?
• Standardien noudatus: Käytetäänkö universaaleja protokollia (OIDC, SCIM), jotka mahdollistavat myöhemmän vaihdon?
• Ei lukitsemista: Proprietaariset API:t, custom-protokollat, ei-standardi tokenit — nämä ovat lukkosignaaleja. Mitä omistetumpi integraatio, sitä vaikeampi vaihtaa pois.

Arviointimatriisi: Käytännön pistetaulukko#

Arvioitua kaikki kohdat, pitää pystyä vertailemaan. Tässä prioriteetti:

P1 — Estävät (pakko olla kunnossa, muuten hylätty)#

P2 — Suositaan vahvasti (iso insinöörityö ilman)#

P3 — Tärkeitä (tarvitaan 12 kk sisään)#

P4 — Kiva olla, ei kriittinen#

Näin käytät tätä: Aloita P1:stä. Jos toimittaja epäonnistuu missään P1-kohdassa, lopeta arviointi. Sitten laske P2- ja P3-kategoriat. Paras yhteispistetulos voittaa.

Yleiset arvioinnin virheet#

Olemme nähneet samat virheet uudestaan. Näin vältät ne:

Virhe 1: Vertailu ominaisuuksilla, ei arkkitehtuurilla#

Ominaisuustaulukko kertoo, mitä on, muttei miten toteutettu. IdP voi "tukea" org-mallia laittamalla org-id:n käyttäjän metadatalle. Taulukkoon rasti, tuotannossa isoja ongelmia.

Korjaus: Jokaisen ominaisuuden kohdalla kysy "miten tämä on toteutettu?" – ei vain "onko tämä teillä?"

Virhe 2: Migraatio unohtuu valinnan jälkeen#

Tiimi valitsee "parhaan" IdP:n, alkaa toteuttaa, ja huomaa etteivät voi siirtää käyttäjiä ilman salasanan vaihtoa. Nyt vaihtoehtoina huono migraatio tai arvioinnin aloitus uusiksi.

Korjaus: Migraatiokyky on ensimmäinen filtteri, ei viimeinen.

Virhe 3: Yliviiva demo#

Demot ovat siistejä, täydellä tietokannalla ja ilman reunaehtoja. Oikea ympäristösi sisältää yhdisteltyjä tilejä, outoa unicodea profiileissa ja sessioita, joita ei pitäisi olla.

Korjaus: Pyydä proof-of-concept omalla datallasi. Tuo 1000 oikeaa käyttäjää ja aja aidot flowt.

Virhe 4: Väärät ihmiset arvioimassa#

Jos vain platform-tiimi arvioi, valitaan teknisesti siistein. Jos vain tuote, helpoiten integroitava. Jos vain tietoturva, eniten compliance-lokeroita.

Korjaus: Arviointitiimissä oltava platform engineering, tuote, sekä tietoturva. Jokaisella omat P1/P2 vastuut.

Virhe 5: Unohtuu, että pitää joskus lähteä#

Vendor lock-in on todellista. Proprietaariset SDK:t, custom-API:t, erikoistokenit — vaikeuttavat siirtymistä myöhemmin.

Korjaus: Suosi IdP:tä, jotka käyttävät standardiprotokollia (OIDC, OAuth2, SCIM). Tuleva itsesi kiittää.

UKK#

Kauanko IdP-arviointi kestää?#

Jos haluat perusteellisen arvioinnin ja proof-of-conceptin, varaa 4–8 viikkoa. Kiirehtiminen johtaa mainittuihin virheisiin – erityisesti migraatio-ongelmaan. Varaudu 2 viikkoon vaatimusten keruulle, 2–3 viikkoon toimittajien arviointiin ja PoC:lle, sekä 1–2 viikkoon sidosryhmien yhteensovittamiseen.

Kannattaako rakentaa oma auth?#

Riippuu vaiheestasi. Jos käyttäjiä alle 10 000 eikä enterprise-asiakkaita, kevyt kirjastoratkaisu käy. Mutta jos tarvitset SSO:n, monivuokrauksen, MFA:n ja compliance-dokumentit, oman authin ylläpito ylittää IdP:n hinnan. Olemme nähneet tiimejä, jotka käyttävät 2–3 kehittäjää ympäri vuoden authin ylläpitoon — 300–500 k€/vuosi menetettyä aikaa.

Erot CIAM ja workforce IAMin välillä?#

Customer Identity and Access Management (CIAM) koskee tuotteen loppukäyttäjiä — rekisteröityminen, kirjautuminen, profiilihallinta. Workforce IAM on työntekijöiden pääsy yrityksen sisäisiin työkaluihin (Okta Slackille, Google Workspace, tms). Eri ostot ja eri arviointikriteerit. Tämä opas on CIAMiin.

Kuinka tärkeä avoin lähdekoodi vs. suljettu?#

Avoin antaa läpinäkyvyyden (voit auditoida koodin), siirrettävyyden (self-host mahdollinen) ja yhteisön kehityksen. Suljetut voivat tarjota viimeistellymmän UI:n ja hallinnoidun palvelun. Avain ei ole "avoin vai suljettu" — vaan "pääsenkö irti jos tarvitsee?" Avoratkaisut ovat helpompia lähteä kun mallit ja API:t ovat julkisesti näkyvissä.

Milloin AI-agentin tunnistautuminen on P1, ei P3?#

Jos jo rakennat AI-ominaisuuksia, jotka käyttävät käyttäjien dataa (copilotit, automatisoidut prosessit, AI-assistentit), siirrä P1:een heti. Jos AI on 6–12 kk suunnitelmassa, Pidä P3:ssa mutta painota korkealle. Jos AI ei edes ole näköpiirissä, P4 riittää – tarkista tilanne puolen vuoden päästä uudestaan.

Miten vertailla hintoja, kun mallit eriävät?#

Useimmat palvelut hinnoittelevat Monthly Active User (MAU) mukaan. Mutta määritelmät vaihtelevat — lasketaan loginia, uniikkia käyttäjää, joskus M2M-tokenit erikseen. Pyydä tarjous omalla skenaariollasi: X käyttäjää, Y organisaatiota, Z M2M-yhteyttä sekä odotettu auth-volyymi. Vertaa kokonaishintaa, ei yksikköhintaa.

Tiivistelmä#

Identiteettitarjoajan valinta on infrastruktuurivalinta, ei ominaisuuspäätös. Sitoudut järjestelmään, joka hoitaa jokaisen käyttäjäsi ensimmäisen kontaktin tuotteeseesi, jokaisen käyttöoikeustarkistuksen ja jokaisen audit-logirivin, jota compliance-tiimisi tarkastaa.

Tämä arviointikehys keskittyy siihen, mikä oikeasti ratkaisee — ei siihen, mitä markkinointikiihko lupaa. Käytä sitä suodattaaksesi ehdokkaat nopeasti (ensin P1), arvioi syvällisesti (P2/P3 proof-of-conceptilla), ja tee päätös, joka kantaa vuosiksi.

Tiimit, jotka onnistuvat tässä, yhdistää yksi asia: ne käsittelevät identiteettiä infrastruktuurina, eivät räplättävänä ominaisuutena.