Ett praktiskt IdP-utvärderingsramverk byggt utifrån verkliga företagskrav. Täcker djupgående protokoll, migrering, multi-tenans, AI-förberedelse och de kriterier som de flesta checklistor missar.
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.
Om du snabbläser, här är den korta versionen:
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.
Detta är för dig om:
Detta är INTE för dig om:
Varje IdP på marknaden säger att de stöder OAuth2 och OIDC. Det är grundkrav. De verkliga frågorna gäller djupet.
Måste ha:
Allt viktigare:
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:
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:
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.
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.
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.
Inte glamoröst. Helt avgörande.
app.dinprodukt.com och ditt API på api.dinprodukt.com, kan sessioner delas mellan subdomäner? Hur?Användare vill vara inloggade i veckor, inte minuter. Men 180-dagars session har andra säkerhetskonsekvenser än 30-minuters.
Fråga:
RBAC är grundnivån. Om IdP inte stöder RBAC, utvärdera inte alls. För B2B SaaS räcker dock inte RBAC.
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:
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:
auth_level-claim som backend kan kontrollera?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.
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.
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.
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:
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.
Om leverantören inte ger säkra svar, har de aldrig gjort detta. Gå vidare.
B2B SaaS = multi-tenans. Dina kunder är organisationer med flera användare, roller och policies. IdP måste förstå detta på riktigt.
Vissa IdPs saknar organisationmodell. De föreslår att använda custom user-metadata (user.app_metadata.org_id = "123").
Detta slutar fungera:
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.
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.
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.
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 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.
Om leverantören inte tänkt på detta bygger de för 2020. Du planerar för 2026.
Funktioner säljer. Drift avgör om du förnyar.
Efter utvärdering av alla dimensioner behöver du jämföra. Här är ett prioriteringsramverk:
| Kriterium | Varför P1 |
|---|---|
| Import av lösenordshashar eller progressiv migrering | Går inte att använda annars |
| Authorization Code + PKCE | Säkerhet grundkrav |
| Inbyggd organisationsmodell | Krav för B2B SaaS |
| SOC2 Typ II, eller tydlig plan dit | Företagskundkrav |
| 99,9 %+ uptime SLA | Auth nere = produkt nere |
| Kriterium | Varför P2 |
|---|---|
| Anpassade JWT claims | Undviker anrop för rättigheter |
| Auth policy per org | Företags-onboarding |
| Org-baserade roller och tokens | Multi-tenant-auktorisation |
| Refresh-token-rotation & revokation | Säkerhetskrav |
| Hosted UI + eget UI-alternativ | Flexibilitet |
| Kriterium | Varför P3 |
|---|---|
| Token Exchange (RFC 8693) | AI-agent-auth |
| OIDC Provider-funktion | Partner-federation |
| Step-up-auth / auth_level | Finans/högrisk |
| SCIM provisionering | Företagskunders synk |
| Passkey / WebAuthn | Lösenordslös riktning |
| Kriterium | Varför P4 |
|---|---|
| Inbyggd analysdashboard | Kan byggas från loggar |
| White-labelade mejlmallar | Bekvämt |
| Visuell flow builder | Bekvämt |
| Fler färdiga social connectors | Långsvans-leverantörer |
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.
Vi har sett samma misstag göras om och om igen. Undvik dem så här:
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...?"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".