Hur du väljer en identitetsleverantör: Teknikteamets utvärderingsramverk

De flesta artiklar som jämför identitetsleverantörer är skrivna av just identitetsleverantörer. Överraskad? De listar funktioner deras produkt har, hoppar över de som saknas och kallar det en "objektiv guide".

Detta är inte en sådan.

Vi har granskat dussintals faktiska utvärderingsförfrågningar från företag — de verkliga kalkylbladen och RFP-dokumenten som inköpsteam skickar till leverantörer. Mönstret är tydligt: teknikteam underskattar konsekvent de kriterier som betyder mest och överskattar de som betyder minst.

Resultatet? Team väljer en IdP baserat på en demo, upptäcker att migreringsberättelsen är en mardröm sex månader senare, och börjar om från början.

Här är utvärderingsramverket vi önskar att någon gett oss innan vi började. Det är byggt för teknikteam i B2B SaaS-företag — de som bygger produkter, inte de som köper arbetskrafts-SSO för sina anställda.

Snabbt svar: Vad avgör en IdP-beslut#

Om du snabbläser, här är den korta versionen:

1. Protokolldjup är viktigare än antalet funktioner. Att "stödja OAuth2" säger ingenting. Vilka grant types? Kan du anpassa token-claims? Kan du själv bli en OIDC-leverantör?
2. Migreringskapacitet är den mest underskattade faktorn. Om du inte kan migrera dina befintliga användare utan att tvinga dem till lösenordsåterställning är IdP:t oanvändbart — oavsett hur bra allt annat ser ut.
3. Multi-tenans måste vara inbyggt, inte pålagt. Om organisationsmodeller och per-tenant-konfigurationer kräver genvägar kommer du att kämpa mot systemet för alltid.
4. AI-förberedelse är inget framtidsplanerande — det är ett krav inom 12 månader. Token exchange, agentidentitet, delegerade scopes. Om IdP:t inte stöder dessa, kommer du att utvärdera på nytt nästa år.

Resten av denna guide går igenom varje dimension i detalj, med specifika frågor att ställa och varningsflaggor att hålla utkik efter.

Vem denna guide är för (och vem den inte är för)#

Detta är för dig om:

• Du är CTO, VP Engineering eller plattformsarkitekt på ett B2B SaaS-företag med 50-300 personer
• Du har 100K+ befintliga användare och har inte råd med en störande migrering
• Du går uppåt på marknaden mot företagskunder som behöver SSO, organisationsmodeller och granskningsloggar
• Du behöver skriva en teknisk utvärderingsrapport och vill ha ett ramverk som inte kommer från en leverantör

Detta är INTE för dig om:

• Du letar efter arbetskrafts-IAM (SSO för anställda till interna verktyg) — det är ett annat köpbeslut
• Du är en startup med 500 användare och inga företagskunder än — välj den som har bäst SDK och gå vidare
• Du behöver identitetsverifiering (KYC/KYB) — det är en helt egen kategori

Dimension 1: Protokollkapabiliteter — Inte bara "stöder OAuth2"#

Varje IdP på marknaden säger att de stöder OAuth2 och OIDC. Det är grundkrav. De verkliga frågorna gäller djupet.

Grant types: Vilka och varför det spelar roll#

Måste ha:

• Authorization Code + PKCE — Det enda flödet du bör använda för webbaserade och mobila appar. Om en leverantör fortfarande rekommenderar Implicit flow, gå därifrån. PKCE är inte valfritt — det är en säkerhetskrav.
• Client Credentials — För service-till-service-kommunikation. Dina backendtjänster behöver autentisera sig mot varandra utan närvarande användare.
• Refresh Token — Låter grundläggande, men implementationsdetaljerna varierar stort. Kan du konfigurera rotation? Utgångstid? Kan du återkalla en specifik refresh-token utan att avsluta hela sessionen?

Allt viktigare:

• Token Exchange (RFC 8693) — Detta är grant type:en som möjliggör AI-agentautentisering, impersonation-flöden och delegering. Om det saknas idag, fråga om det finns på planen. Om det inte finns någon plan — röd flagga.

OIDC Provider-kapacitet#

Här är en fråga de flesta team inte tänker på att ställa: Kan du använda denna IdP som en OIDC-leverantör — inte bara som OIDC-konsument?

Varför det spelar roll: När din SaaS växer kan partners och kunder vilja använda ditt identitetssystem för att logga in i sina egna verktyg. Du behöver utfärda tokens, hantera samtycke och administrera tredjeparts-appar. Om din IdP bara låter dig konsumera externa identitetsleverantörer men inte själv kan agera som en, kommer du att slå i väggen när du behöver utgående federation.

Fråga:

• Exponerar IdP:t en OpenID Discovery-endpoint som du kan white-labela?
• Kan du registrera förstaparts- och tredjepartsapplikationer med olika förtroendenivåer?
• Kan förstapartsappar hoppa över samtyckesskärmen medan tredjeparts-appar kräver den?

JWT-anpassning#

Token är kontraktet mellan din IdP och dina tjänster. Om du inte kan anpassa det, måste varje efterföljande tjänst göra ytterligare API-anrop för att ta reda på vad en användare får göra.

Fråga:

• Kan du lägga till anpassade claims till access- och ID-tokens?
• Kan du bädda in organisationskontext (vilken tenant användaren arbetar i) direkt i token?
• Kan du definiera anpassade scopes som motsvarar din applikations rättighetsmodell?
• Räknas claims fram vid tokenutgivning, eller kan de fyllas dynamiskt via webhook eller skript?

En token som innehåller { "org_id": "org_123", "role": "admin", "auth_level": 2 } gör att ditt API-middleware kan fatta auktorisationsbeslut på en rad. En token som bara innehåller { "sub": "user_456" } innebär att varje tjänst måste göra en callback till IdP eller databas för resten. I skala är skillnaden mellan 2 ms och 200 ms per förfrågan.

Dimension 2: Autentiseringsflöden — Detaljerna som fäller dig#

Alla IdPs stöder e-post/lösenord och social inloggning. Grattis, du har nuvalt ner fältet till... alla.

Skillnaden ligger i detaljerna som de flesta demos inte täcker.

Registreringsflödet#

• Auto-login efter registrering: Loggas användaren in automatiskt efter registrering? Eller får de se inloggningssidan igen? Att tvinga användaren att logga in direkt efter registrering dödar konverteringar. Många IdPs missar detta.
• Anpassade registreringsfält: Kan du samla in roll, företagsnamn eller användningsområde vid sign-up? Eller behövs en separat onboarding efteråt?
• Progressiv profilering: Kan du samla mer info över flera sessioner, istället för att kräva allt på en gång?

Inloggningsflödet#

• Stöd för login_hint: När en användare klickar en länk från ett marknadsföringsmejl, kan du förifylla deras e-postadress? Låter trivialt, är det inte. Gör skillnaden mellan 40 % och 60 % conversion rate på e-postkampanjer.
• Organisationsspecifika autentiseringspolicies: Kan Org A kräva SAML SSO medan Org B kör e-post/lösenord? Kan du tvinga MFA endast för företagstenants? Om per-tenant-policies kräver kod istället för konfiguration, slösar du ingenjörstid varje gång en ny företagstenant onboardas.
• Anpassning av brandning: Kan du anpassa inloggningsupplevelsen per tenant? Inte bara logotyp och färger — full CSS-kontroll, egna domäner och white-labelade mejl. "Hosted UI vs. eget UI" ska vara ett val, inte en begränsning.

Vad de flesta checklistor missar#

• Tyst autentisering: När en token går ut, kan appen förnya den i bakgrunden utan redirect? Vad händer om refresh-token också gått ut — finns fallback (ex. förlängd session via iframe)?
• Konto-länkning: En användare registrerar sig via Google och försöker sedan logga in med e-post. Två konton eller ett? Hur hanterar IdP identitetssammanslagning? Fel här ger eviga dubbletter.
• Lösenordslösa alternativ: Magiska länkar, passkeys, WebAuthn. Inte alla behöver det idag, men dina företagskunder kommer fråga om det inom 6 månader.

Dimension 3: Session- och tokenhantering — På djupt vatten#

Här skiljs utvärderingar från demos. Hantering av sessioner och tokens är tråkigt tills det går snett — då loggas alla ut samtidigt.

Cookiekonfiguration och säkerhet#

Inte glamoröst. Helt avgörande.

• HttpOnly, Secure, SameSite-attribut: Alla tre måste vara korrekt inställda. IdP utan HttpOnly på sessionscookies är inte redo för produktion.
• Stöd för subdomäner: Om din app kör på app.dinprodukt.com och ditt API på api.dinprodukt.com, kan sessioner delas mellan subdomäner? Hur?
• Tredjepartscookies fasas ut: Chrome plockar bort dem. Hur hanterar IdP cross-origin-auth utan tredjepartscookies? "Vi jobbar på det" duger inte.

Remember me och persistenta sessioner#

Användare vill vara inloggade i veckor, inte minuter. Men 180-dagars session har andra säkerhetskonsekvenser än 30-minuters.

Fråga:

• Kan du konfigurera sessionslängd oberoende av tokenlivslängd?
• Finns "remember me" som låter sessionen leva längre men håller tokens korta?
• Kan du kräva återautentisering för känsliga operationer utan att avsluta sessionen?

Refresh-token-säkerhet#

• Tokenrotation: Roteras refresh-tokens vid varje användning? (Borde så vara.)
• Krypterad lagring: Är refresh-tokens krypterade i vila?
• Revokationsgranularitet: Kan du återkalla en specifik enhets session utan att avsluta alla?
• Konfigurerbar utgångstid: Olika appar, olika behov. Går det per applikation eller globalt?

Dimension 4: Auktorisationsmodell — Mer än grundläggande RBAC#

RBAC är grundnivån. Om IdP inte stöder RBAC, utvärdera inte alls. För B2B SaaS räcker dock inte RBAC.

Organisationsbaserade rättigheter#

Dina användare tillhör organisationer. Deras rättigheter i varje organisation skiljer sig från plattformsnivån.

En användare kan vara admin i Org A och läsare i Org B. Samma användare, två olika roller. Om IdP inte kan modellera detta måste du bygga eget rättighetssystem — nu har du två sanningar.

Frågor:

• Kan du definiera roller per organisation, inte bara för användaren?
• Kan en och samma användare ha olika roller i olika organisationer?
• Ligger organisationskontexten i token, så att API vet vilken org användaren arbetar i?

Flera nivåers auktorisation (auth_level)#

Finansiella appar, sjukvård, eller produkter med högriskåtgärder: inte alla sessioner är likvärdiga.

Titta på dashboard? Sessionscookie räcker. Initiera banköverföring? Då krävs MFA även för inloggade.

Detta är "step-up"-autentisering och kräver ett autentiseringsnivå-begrepp (auth_level) i tokensystemet.

Fråga:

• Kan token innehålla ett auth_level-claim som backend kan kontrollera?
• Kan du utlösa step-up-autentisering utan full om-inloggning?
• Har auth_level egen utgångstid, oberoende av sessionen?

Om IdP inte stöder detta får du bygga det själv — exakt den sorts identitetslogik man vill slippa genom IdP.

Auktorisationsbeslut baserat på token#

Ideal: middleware läser token, ser användarens org, roll och auth level och tar beslutet utan extern tjänst.

Med många IdPs: token säger vem användaren är, men man måste slå API för att se vad hen får göra.

Det extra anropet ökar latens, beroenden, och felkällor. Vid 1000 rps vill du inte att auktorisationskontrollen gör nätverksanrop.

Dimension 5: Migrering — Kriteriet som avgör allt#

En statistik ingen vill prata om: de flesta IdP-utvärderingar avbryts inte för att IdP är för dålig, utan för att teamet inte kan migrera sina användare.

Om du har 100K+ användare är migrering inte "nice to have" — det är hela projektet.

Tre migreringsstrategier (och vilka IdP måste stödja)#

1. Massimport med befintliga lösenordshashar

Dina användare har lösenord i t.ex. bcrypt, argon2 eller annat. Kan IdP importera dessa hashat direkt och verifiera lösenord mot dem?

Ja: användaren märker ingenting, loggar in som vanligt. Bästa scenario.

Nej: alla får "återställ lösenord"-mail. Du tappar 30–50 % av användarbasen. Detta händer på riktigt.

2. Progressiv (lat) migrering

Istället för att migrera alla på en gång, migreras de när de loggar in. Första inloggning verifieras i gamla systemet och skapar användaren i nya IdP. Nästa login går till nya IdP direkt.

Säkrast för stora baser, men kräver stöd för:

• Anpassad autentiserings-hook som anropar legacy
• Skapa användare "on-the-fly"
• Hålla koll på vilka som är migrerade

3. Dual-write (parallell drift)

Både gamla och nya systemet körs. Skrivningar går till båda, läsningar flyttas gradvis. Ger rollback, men ökar komplexitet.

Varningsflaggor vid migrering#

• "Vi stödjer CSV-import" — Gäller användarprofiler, inte lösenord. Behöver ändå lösenordsåterställning.
• "Vi har en migreringsguide" — Läs noga. Om det står "användarna behöver nytt lösenord", förlorar du 30-50 %!
• Ingen hash-kompatibilitet nämnd — Har leverantören inte tänkt på hash-migrering, har de inga kunder i din skala.

Frågor att ställa#

• Vilka lösenordshashalgoritmer kan ni importera? (bcrypt, argon2, scrypt, PBKDF2, egen?)
• Kan vi köra progressiv migrering vid första login?
• Kan vi spåra migreringsgrad — andel migrerade?
• Vad är rollback-strategin?
• Kan vi bibehålla sessioner så ingen loggas ut under migrering?

Om leverantören inte ger säkra svar, har de aldrig gjort detta. Gå vidare.

Dimension 6: Multi-tenans — Inbyggt eller efterkonstruerat#

B2B SaaS = multi-tenans. Dina kunder är organisationer med flera användare, roller och policies. IdP måste förstå detta på riktigt.

Vad "inbyggd multi-tenans" betyder#

• Organisation som förstas klassens begrepp: Inte ett eget fält i användarprofilen, utan en datastruktur med eget ID, konfiguration och medlemslista.
• Autentiseringspolicy per organisation: Org A kör SAML SSO, Org B kör e-post/lösenord med MFA, Org C loggar in med Google. Allt via UI eller API, inte kod.
• Medlemskap & inbjudningar: Admins i varje org kan bjuda in, ge roller, ta bort användare. IdP sköter flödet, mejlbekräftelse, rollhantering.
• Tokens i organisationskontext: När användaren verkar i en org, så bär token med org-info. API vet vilken orgs data den ska återge.

"Custom metadata"-genvägen#

Vissa IdPs saknar organisationmodell. De föreslår att använda custom user-metadata (user.app_metadata.org_id = "123").

Detta slutar fungera:

• Multi-org kräver array-hantering i metadata
• Ingen inbyggd inbjudan eller medlemsflöde
• Ingen policy per org
• Ingen org-token — du måste härleda från andra signaler
• Granskningsloggar saknar organisationer

Om leverantören säger "ni kan modellera orgs i metadata" är det som att lagra relationsdata i en JSON-kolumn. Det funkar — tills det inte gör det.

Frågor att ställa#

• Är organisationsmodellen inbyggd eller pålagd på metadata?
• Kan användare tillhöra flera organisationer samtidigt?
• Kan vi konfigurera olika autentiseringskrav per organisation?
• Är organisation-specifika rättigheter inbyggda?
• Kan org-admins hantera medlemmar via självservice-UI?
• Inkluderar token org-kontekst?

Dimension 7: AI-förberedelse — Kriteriet ingen (än) frågar efter#

För 12 månader sedan nämndes aldrig "AI-agentautentisering" i checklistor. Idag, om du bygger in AI i produkten — co-pilots, agenter, AI-baserade flöden — måste IdP stödja en ny identitetstyp: agenten.

Därför fungerar inte klassisk modell för agenter#

Traditionell auth: två aktörer — användare och applikation. OAuth2 är byggt så.

AI-agenter introducerar en tredje: en icke-mänsklig entitet, som agerar för en användare, med avgränsade rättigheter och egen granskningslogg.

• En agent är inte en användare — har varken lösenord eller websession
• En agent är inte en maskintjänst — agerar å användarens vägnar
• Agenten behöver scoped, tidsbegränsad behörighet — inte full access

Vad IdP måste stödja#

Token Exchange (RFC 8693): Agenten visar egen legitimation plus användarens tillåtelse, får en avgränsad token. Tokenen bär: vem (användare), vad (agent), scope (behörighetsgräns), när (utgångstid).

Agent som klienttyp: Agenten bör modelleras som riktig OAuth2-klient med egen client_id, inte via API-nycklar eller delade tokens.

Delegerad scopehantering: Användaren kan ge agenten begränsade rättigheter — t.ex. bara läs, bara åtkomst till vissa resurser.

Audit-åtskillnad: Loggen måste särskilja "användare gjorde X" och "agent gjorde X för användaren". Missar du detta misslyckas du i nästa SOC2-audit.

MCP (Model Context Protocol)-kompatibilitet#

MCP blir standard för att AI-agenter ska kunna interagera med tjänster. Om IdP stödjer OAuth-baserauth för MCP-servrar kan agenter autentisera via protokoll, inte API-nycklar.

Frågor att ställa#

• Stödjer ni OAuth2 Token Exchange?
• Kan agenter modelleras som separata klienttyper?
• Kan tokens bära delegeringsinfo (vem gav agenten tillåtelse, vilket scope)?
• Särskiljer granskningsloggen agenthandlingar och mänskliga?
• Finns MCP-integration eller OAuth för agent-till-verktyg-auth?

Om leverantören inte tänkt på detta bygger de för 2020. Du planerar för 2026.

Dimension 8: Icke-funktionella krav — Det som oroar dig på natten#

Funktioner säljer. Drift avgör om du förnyar.

Prestanda#

• Autentiseringskapacitet: Klarar systemet 100+ auth-förfrågningar per sekund? 1 000+?
• Tokenverifieringslatens: Verifierar dina tjänster JWTs lokalt (ska de), blir det sub-millisecond. Om IdP kräver introspectionsanrop, vad är P99-latensen?
• Skalningstak: Max antal MAU? Har de visat det i produktion?

Efterlevnad#

• SOC2 Typ II: Inte bara Typ I. Typ II = reviderad över tid. Typ I = vid en tidpunkt. Finns bara Typ I, fråga efter plan mot Typ II.
• Granskningsloggar: Varje authhändelse, rättighetsändring, adminåtgärd ska loggas. Kan du exportera till SIEM? Är loggarna oföränderliga?
• Datahemvist: Kan du styra region där användardata lagras? För EU är detta ett måste.

Tillförlitlighet#

• Uptime SLA: 99,9 % låter bra — men ger 8,7 h nedtid/år. 99,99 % är 52 min. För auth — "dörren" till din app — spelar det roll.
• Failover: Vad händer vid idP-avbrott? Finns fallback? Multi-region?
• Incidenthistorik: Kolla status-page. Inte löften, verklighet.

Dataportabilitet#

• Användarexport: Kan du exportera alla användardata inkl. metadata, organisationsmedlemskap, roller? Format?
• Standarder: Använder IdP standardprotokoll (OIDC, SCIM) för enklare migrering?
• Anti-lås-in-signal: Proprietära API:er, egna tokenformat = svåra att lämna. Ju mer eget, desto svårare att migrera.

Utvärderingsmatrisen: Ett praktiskt poängsystem#

Efter utvärdering av alla dimensioner behöver du jämföra. Här är ett prioriteringsramverk:

P1 — Deal-breakers (måste klara — annars ut)#

P2 — Stark preferens (kostar mycket tid att sakna)#

P3 — Viktiga (planeras inom 12 månader)#

P4 — Trevliga att ha (ej avgörande)#

Så här använder du den: Börja med P1. Om en leverantör inte klarar någon P1 — sluta utvärdera den. Poängsätt sedan P2 och P3. Den med bäst P2+P3 totalt vinner.

Vanliga utvärderingsmisstag#

Vi har sett samma misstag göras om och om igen. Undvik dem så här:

Misstag 1: Fokus på funktioner, inte arkitektur#

En funktionstabell visar vad som finns. Den avslöjar inte HUR det är byggt. En IdP kan "stötta" organisationer genom att lagra org-ID i metadata — ser bra ut på papper, blir problem i produktion.

Lösning: Fråga "hur har ni implementerat detta?" — inte bara "har ni...?"

Misstag 2: Ignorera migrering tills efter valet#

Man väljer "bästa" IdP, börjar bygga, och inser sen att migrationsstrategin kräver lösenordsreset. Nu måste man antingen acceptera dålig migrering eller börja om.

Lösning: Gör migreringskapacitet till första filter, inte sista.

Misstag 3: Övervärdera demon#

Alla demos är perfekta. Inga edge-cases. Din produktion har sammanslagna konton, konstiga unicode och "spök-sessioner".

Lösning: Kräva proof of concept på ERA-data. Importera 1 000 riktiga användare, kör riktiga flöden.

Misstag 4: Fel personer utvärderar#

Bara plattformsteam? Då väljer de tekniskt snyggast. Bara produkt? Väljer lättast att integrera. Bara säkerhet? Väljer mest compliance.

Lösning: Ta med plattform, produkt och säkerhet i utvärderingen. Alla äger olika P1/P2-kriterier.

Misstag 5: Glömma att du en dag måste lämna leverantören#

Vendor lock-in är verkligt. Proprietära SDK:er, apier, egna tokenformat — allt gör framtida byte svårare.

Lösning: Föredra IdPs med standardprotokoll (OIDC, OAuth2, SCIM). Tacka dig själv senare.

FAQ#

Hur lång tid tar en IdP-utvärdering vanligtvis?#

Med proof of concept, räkna med 4–8 veckor. Skynda leder ofta till migreringsmissar. Räkna med 2 veckor för krav, 2–3 för leverantör + PoC, 1–2 för samordning.

Borde vi bygga egen autentisering istället?#

Beror på fas. Har du < 10 000 användare och inga företagskunder funkar ett bibliotek. Behöver du SSO, multi-tenans, MFA och compliance, blir egen auth dyrare än IdP. Ofta 2–3 heltidstekniker = 3–500 000 USD/år i tappad utvecklingstid.

Vad är skillnaden på CIAM och workforce IAM?#

Customer Identity and Access Management (CIAM): produktslutanvändare — sign-up, login, profilhantering. Workforce IAM: anställda till interna verktyg (Okta till Slack / Google osv.). Olika köpbeslut, olika utvärderingskriterier. Guiden rör CIAM.

Hur viktigt är open source vs. proprietär?#

Open source = insyn (kan granska kod), portabilitet (kan självhosta om nödvändigt), community-bidrag. Proprietärt = ofta snyggare UI, färdighostade tjänster. Nyckelfråga: "Kan jag lämna om det behövs?" Open source ger oftast lättare exit eftersom data och API är publika.

När ska AI-agentauth vara P1 istället för P3?#

Bygger ni redan AI-funktioner som använder användardata för användarens räkning (co-pilots, automatiserade flöden), flytta till P1 nu. Ligger AI på 6–12 månaders plan, behåll under P3 men prioritera högt. Är AI långt bort, sätt P4 — men omvärdera om 6 månader.

Hur utvärderar vi pris när leverantörer har olika modeller?#

De flesta prisar på MAU. Men "MAU" tolkas olika — vissa räknar varje login, andra unika användare, vissa separerar M2M-tokens. Be leverantören räkna på DITT fall: X användare, Y organisationer, Z M2M, din auth-volym. Jämför totalsumma, inte enhetspris.

Slutsats#

Att välja IdP är ett infrastrukturbeslut, inte ett funktionsbeslut. Du förbinder dig till det som hanterar varje användares första kontakt med din produkt, varje permissionskontroll i API:t och varje audit log för compliance.

Ramverket ovan fokuserar på det som faktiskt spelar roll — inte marknadsfloskler. Använd det för att filtrera snabbt (P1 först), utvärdera djupt (P2 och P3 med PoC) och ta ett beslut som håller i år, inte månader.

Team som lyckas har en sak gemensamt: de ser identitet som infrastruktur, inte som en produktfunktion att "skicka och glömma".