OpenID Connect: vad är det, autentiserings- och auktoriseringsprotokoll

Vad är OpenID Connect?

OpenID Connect (OIDC) — är ett öppet autentiseringsprotokoll byggt som ett lager ovanpå OAuth 2.0. Det standardiserar vad som saknades i OAuth 2.0: verifiering av användarens identitet. Om OAuth 2.0 svarar på frågan ”vilken app har åtkomst?”, så svarar OIDC på frågan ” vem är exakt den här användaren?”.

Protokollet använder ID Token — en JSON Web Token (JWT) som innehåller en uppsättning claims: unik identifierare för subjektet, e-post, namn, avatar, tidsstämplar för utfärdande och utgång. Klientappen kan kryptografiskt verifiera ID Token — servern signerar token med RS256 eller ES256, och klienten kontrollerar signaturen med den offentliga nyckeln som erhålls via JWKS-endpointen.

Enligt uppgifter från Auth0, 2025 använder över 78 % av mobilappar som använder tredjepartsautentisering OIDC via Google Sign-In eller Sign in with Apple. Detta gör protokollet till de facto-standard för social inloggning och företagsautentisering.

Hur fungerar OpenID Connect

OpenID Connect definierar flera flöden (flows) beroende på klienttyp. För mobilappar är standarden Authorisation Code Flow med Proof Key for Code Exchange (PKCE) — ger skydd även utan client secret på enheten.

Identity Provider och dess roll

Identity Provider (IdP) — är servern som utför användarautentisering och utfärdar tokens. I OIDC-ekosystemet tillhandahåller IdP två viktiga endpoints: Authorisation Endpoint för användarinloggning och Token Endpoint för utbyte av kod mot tokens. Klienten får reda på adresserna till dessa endpoints via Discovery URL — den standardiserade sökvägen /.well-known/openid-configuration, som returnerar ett JSON-dokument med leverantörens fullständiga konfiguration.

Varje IdP publicerar sin egen JWKS (JSON Web Key Set) — en uppsättning offentliga nycklar för att verifiera ID Token-signaturen. Klienten cachelagrar dessa nycklar och använder dem för att verifiera varje mottagen token utan att kontakta servern.

Authorisation Code Flow med PKCE

Authorisation Code Flow — är en trestegsprocess. Först genererar mobilappen en code verifier (slumpmässig sträng på 43–128 tecken) och dess hash — code challenge. Appen öppnar en webbläsare eller WebView med en URL som innehåller client_id, redirect_uri, scope (openid profile email) och code challenge. Användaren anger inloggningsuppgifter på IdP-sidan och bekräftar samtycke. IdP omdirigerar webbläsaren tillbaka till appen med en authorisation code.

I det andra steget skickar appen authorisation code, code verifier och client_id till serverns Token Endpoint. Servern kontrollerar code verifier mot den lagrade code challenge och returnerar ID Token, Access Token och eventuellt Refresh Token. I det tredje steget verifierar appen ID Token: validerar signaturen via JWKS, kontrollerar issuer (iss), audience (aud) och utgångstid (exp). Om verifieringen lyckas — anses användaren vara autentiserad.

PKCE (Proof Key for Code Exchange) eliminerar den sårbarhet som är inneboende i standard Authorisation Code Flow för offentliga klienter. Eftersom mobilappen inte säkert kan lagra client secret, skulle en angripare som fångat upp authorisation code kunna byta ut den mot tokens. Code verifier löser detta problem: även om koden fångas upp är utbyte utan den ursprungliga code verifier omöjlig. OAuth Security Best Practices (RFC 9700) kräver PKCE för alla offentliga klienter, inklusive mobilappar.

ID Token och Access Token

OpenID Connect returnerar två fundamentalt olika tokens: ID Token och Access Token. ID Token — är alltid en JWT som klienten självständigt kan läsa och verifiera. Den innehåller information om användaren och används för autentisering, inte för API-åtkomst.

Struktur för ID Token

ID Token består av header, payload och signature, kodade i Base64 och separerade med punkter. Header innehåller alg (signaturalgoritm) och kid (nyckelidentifierare). Payload innehåller obligatoriska claims: iss (issuer — utfärdare av token), sub (subject — användarens unika ID), aud (audience — klientens identifierare), exp (expiration), iat (issued at). Valfritt — name, email, picture, locale.

Exempel på avkodad payload för en ID Token från Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token — är en ogenomskinlig token (godtycklig sträng) eller JWT som klienten skickar i API-förfrågningar. Till skillnad från ID Token är access token inte avsedd att läsas av klienten — dess format och innehåll är endast kända för resurservern och auktoriseringsservern. Access Token har scope — begränsning av åtkomsträttigheter — och kort livslängd, vanligtvis 15–60 minuter.

Skillnader mellan OpenID Connect och OAuth 2.0

OAuth 2.0 — är ett auktoriseringsramverk som definierar hur en app får åtkomst till användarens resurser. OpenID Connect — är ett lager som lägger till autentisering till denna process. Huvudskillnad: OAuth 2.0 definierar inte tokenformat och ger inte appen något sätt att veta vem som exakt gjorde förfrågan.

När ska man välja OpenID Connect

OpenID Connect är nödvändigt när appen behöver känna igen användaren, inte bara få åtkomst till dennes data. Om du använder ”Logga in med Google” eller ”Sign in with Apple” — är detta OIDC. Om din app anropar ett tredjeparts-API för användarens räkning utan att behöva känna till dennes identitet — räcker ren OAuth 2.0. För företagssystem med Single Sign-On (SSO) är valet tydligt: bara OpenID Connect, eftersom det tillhandahåller standardiserad utloggning och sessionshantering.

Implementering av OpenID Connect i mobilappar

Integrering av OpenID Connect i en mobilapp kräver val av lämpligt bibliotek och korrekt konfiguration av flödet. För Android används credential manager (AndroidX Credentials) eller AppAuth-biblioteket. För iOS — AuthenticationServices-ramverket med ASWebAuthenticationSession.

Exempelkod i Kotlin (Android)

Nedan finns ett exempel på att starta Authorisation Code Flow med AppAuth-Android-biblioteket. Appen skapar en auktoriseringsbegäran, öppnar en webbläsare för användarinloggning och bearbetar callback med tokens.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Exempelkod i Swift (iOS)

ASWebAuthenticationSession från Apple tillhandahåller en inbyggd webbläsare för OIDC-flödet med SSO-stöd via iCloud Keychain. Sessionen startas med auktoriserings-URL:en och callback bearbetas via en completion handler.

När du väljer bibliotek för OpenID Connect, överväg inbyggt PKCE-stöd: AppAuth-Android och AppAuth-iOS stöder PKCE som standard. Firebase Authentication använder OIDC under huven för Google Sign-In, Sign in with Apple och Microsoft — utvecklaren behöver inte implementera flödet manuellt. För företagssystem med egen IdP (t.ex. Keycloak eller Okta) förblir AppAuth standardvalet med full kontroll över konfiguration och felhantering.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()