Legal

OAuth 2.0 & OpenID Connect SSO

Fullständig guide för att integrera OpenID Connect single sign-on med Advanza.

Last updated: 26 augusti 2026

Översikt

Advanza är en multitenant SaaS-marknadsföringsplattform som stöder OpenID Connect (OIDC) och OAuth 2.0 för säker autentisering och single sign-on (SSO). Den här guiden går igenom stödda flöden, endpoints, scopes och bästa praxis för att integrera Advanzas autentisering i dina applikationer.

Protokoll: OpenID Connect 1.0 (byggt på OAuth 2.0 Authorization Code Grant)
Leverantör: Advanza (via OpenIddict 5.x)
Multi-tenancy: Fullt stöd – varje organisation är en separat tenant
Säkerhet: HTTPS krävs, PKCE rekommenderas för SPA:er, certifikat för konfidentiella klienter

Stödda autentiseringsflöden

Authorization Code Flow (rekommenderas)

OAuth 2.0 Authorization Code Flow är det rekommenderade och säkraste flödet för de flesta applikationer, inklusive webbappar och single-page applications (SPA:er). Det använder PKCE (Proof Key for Code Exchange) för publika klienter för att förhindra att auktoriseringskoder kapas.

Passar bäst för: Webbapplikationer, SPA:er, mobilappar, tredjepartsintegrationer

Refresh Token Flow

Använd refresh tokens för att få nya access tokens utan att användaren behöver logga in igen. Refresh tokens är giltiga i 14 dagar och kan roteras för att bibehålla säkerheten.

Passar bäst för: Långvariga sessioner, bakgrundstjänster, offline-åtkomst

Client Credentials Flow (äldre)

OAuth 2.0 Resource Owner Password Credentials-flödet stöds för bakåtkompatibilitet med äldre integrationer. Nya integrationer bör istället använda Authorization Code Flow.

Passar bäst för: Äldre applikationer, interna verktyg (rekommenderas inte för ny utveckling)

API-endpoints

Alla endpoints finns på https://api.advanza.ai

Authorization-endpoint

GET /connect/authorize

Startar OAuth-auktoriseringsflödet. Omdirigerar användaren för att logga in med sin identitetsleverantör (Microsoft, Google, eller e-post/lösenord).

Query-parametrar:

  • client_id (obligatorisk): Ditt applikations-ID
  • redirect_uri (obligatorisk): URL att omdirigera till efter autentisering
  • response_type (obligatorisk): Måste vara 'code'
  • scope (obligatorisk): Mellanslagsseparerad lista av scopes (openid, email, profile, offline_access, roles)
  • code_challenge (obligatorisk för SPA): PKCE code challenge
  • code_challenge_method (obligatorisk tillsammans med code_challenge): 'S256'
  • state (rekommenderas): Slumpmässig sträng för att förhindra CSRF-attacker
  • tenant_id (valfri): Specifik tenant att autentisera mot

Token-endpoint

POST /connect/token

Byter en auktoriseringskod mot access token, ID-token, och eventuell refresh token.

Requestformat: application/x-www-form-urlencoded

Parametrar:

  • grant_type (obligatorisk): 'authorization_code', 'refresh_token', eller 'password'
  • code (obligatorisk för auth code flow): Auktoriseringskod från /authorize
  • client_id (obligatorisk): Ditt applikations-ID
  • client_secret (obligatorisk): Din applikationshemlighet (håll konfidentiell)
  • redirect_uri (obligatorisk): Måste matcha /authorize-anropet
  • code_verifier (obligatorisk för SPA): PKCE code verifier
  • refresh_token (för refresh-flöde): Refresh token som ska bytas ut
  • username & password (för password-flöde): Användaruppgifter

Token Introspection-endpoint

POST /connect/introspect

Validerar och inspekterar innehållet i en access token eller refresh token.

OpenID-konfiguration

GET /.well-known/openid-configuration

Standard OIDC-metadata-endpoint. Returnerar discovery-information inklusive endpoints, publika nycklar, stödda scopes och grant types.

Scopes

Begär scopes via scope -parametern i auktoriseringsanropet:

openid (obligatorisk)

Begär en ID-token med användarens identitetsinformation (subject claim, namn, tenant-ID, etc.)

email

Begär användarens e-postadress och verifieringsstatus

profile

Begär användarens profilinformation: name, given_name, family_name

offline_access

Begär en refresh token för att förlänga åtkomsten utan att kräva ny autentisering

roles

Begär användarens roller/behörigheter (t.ex. "Owner", "Editor", "Viewer")

Minsta scope för inloggning: openid email profile

Exempel: Authorization Code Flow med PKCE

Det här exemplet visar det rekommenderade flödet för single-page applications (SPA:er) och mobilappar.

Steg 1: Generera PKCE-challenge

Skapa en code verifier och challenge på klientsidan:

// 1. Generate random code verifier (43-128 characters)
const codeVerifier = generateRandomString(128);

// 2. Create code challenge via SHA256 hash
const codeChallenge = await crypto.subtle.digest('SHA-256',
  new TextEncoder().encode(codeVerifier)
);

// 3. Base64-URL encode the challenge
const codeChallengeB64 = base64UrlEncode(codeChallenge);

// Store codeVerifier in sessionStorage for Step 3
sessionStorage.setItem('pkce_verifier', codeVerifier);

Steg 2: Omdirigera till authorization-endpointen

Skicka användaren till inloggning:

GET /connect/authorize?
  client_id={your_app_id}
  &redirect_uri=https://your-app.com/callback
  &response_type=code
  &scope=openid email profile
  &code_challenge={pkce_challenge}
  &state={random_state}

Användaren omdirigeras till sin identitetsleverantör (Microsoft, Google, eller e-post/lösenord), slutför autentiseringen och omdirigeras tillbaka till din redirect_uri med en auktoriseringskod.

Steg 3: Byt kod mot tokens

Byt auktoriseringskoden från din backend:

POST /connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code={auth_code}
&client_id={your_app_id}
&client_secret={your_app_secret}
&redirect_uri=https://your-app.com/callback
&code_verifier={pkce_verifier}

Steg 4: Token-svar

Vid lyckat anrop får du:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "DefxA1234567890...",
  "id_token": "eyJhbGciOiJSUzI1NiIs..."
}

Steg 5: Verifiera ID-token

Validera ID-tokens signatur med den publika nyckeln från /.well-known/openid-configuration, verifiera issuer- och audience-claims, och extrahera användarinformation.

Token-claims

ID Token-claims

ID-token (JWT) innehåller användarens identitetsinformation:

{
  "sub": "550e8400-e29b-41d4-a716-446655440000",
  "email": "user@company.com",
  "email_verified": true,
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "tenant_id": "12345678-1234-1234-1234-123456789012",
  "iss": "https://api.advanza.ai",
  "aud": "your_app_id",
  "iat": 1234567890,
  "exp": 1234571490
}

Viktiga claims:

  • sub: Unik användaridentifierare (Guid)
  • email: Användarens e-postadress
  • email_verified: Om e-posten är verifierad
  • name, given_name, family_name: Användarens namn
  • tenant_id: Användarens aktiva tenant/organisation
  • iss: Token-utfärdare (alltid https://api.advanza.ai)
  • aud: Avsedd mottagare (ditt applikations-ID)
  • iat: Tidpunkt då token utfärdades (Unix-tidsstämpel)
  • exp: Tokens utgångstid (Unix-tidsstämpel)

Access Token-claims

Access-token (JWT) innehåller auktoriseringsinformation:

{
  "sub": "550e8400-e29b-41d4-a716-446655440000",
  "email": "user@company.com",
  "name": "John Doe",
  "tenant_id": "12345678-1234-1234-1234-123456789012",
  "roles": ["Owner"],
  "scope": "openid email profile offline_access roles",
  "iss": "https://api.advanza.ai",
  "aud": "your_app_id",
  "iat": 1234567890,
  "exp": 1234571490
}

Viktiga claims:

  • sub: Användar-ID
  • email, name: Användarinformation
  • tenant_id: Aktiv tenant (används för multi-tenancy-routning)
  • roles: Användarens roller i tenanten
  • scope: Beviljade scopes
  • exp: Utgångstid (vanligtvis 1 timme)

Använd access token för: Inkludera i Authorization-headern (Authorization: Bearer {access_token}) när du anropar Advanzas API:er eller din backend.

Multi-tenancy

Advanza är en multitenant-plattform. Varje användare kan vara medlem i flera organisationer (tenants). Claimet tenant_id i både ID- och access-token anger användarens aktiva tenant-kontext.

Standardtenant

Vid första inloggningen tilldelas användaren en standardtenant. Claimet tenant_id fylls i med den tenantens ID.

Byta tenant

Användare med flera tenant-medlemskap kan byta tenant genom att skicka med önskad tenant_id -parameter till authorization-endpointen:

GET /connect/authorize?
  client_id={your_app_id}
  &redirect_uri=https://your-app.com/callback
  &response_type=code
  &scope=openid email profile
  &tenant_id=12345678-1234-1234-1234-123456789012
  &code_challenge={pkce_challenge}

Routning per tenant

Använd tenant_id -claimet för att routa anrop till rätt tenant-kontext i din backend:

// Extract tenant from token claims
const tenantId = tokenClaims.tenant_id;

// Route request to tenant context
const tenantContext = getTenantContext(tenantId);
const result = await performAction(tenantContext, action);

Bästa praxis för säkerhet

Använd HTTPS i produktion

Alla OAuth-anrop måste använda HTTPS för att skydda uppgifter och tokens.

PKCE för SPA:er och mobilappar

Använd alltid PKCE (Proof Key for Code Exchange) för publika klienter. Det förhindrar att auktoriseringskoder kapas.

Håll client secret konfidentiell

Exponera aldrig din client secret i klientkod, loggar eller versionshantering. Använd den bara i säker backend-till-backend-kommunikation.

Validera state-parametern

Generera och validera alltid state -parametern för att förhindra CSRF-attacker.

Verifiera token-signaturer

Validera alltid signaturerna på ID-token och access-token med den publika nyckeln från OIDC-konfigurationsendpointen innan du litar på innehållet.

Hantera refresh tokens säkert

Lagra refresh tokens säkert (HttpOnly-cookies eller säker lagring, inte localStorage). Sätt lämpliga utgångstider.

Hantera tokens utgång

Access-tokens går ut efter 60 minuter. Implementera logik för att förnya tokens för oavbruten åtkomst.

Support

Har du frågor, problem eller behöver hjälp med integrationen? Kontakta vårt supportteam:

E-post: support@advanza.ai
Dokumentation: https://advanza.ai/docs
Status: https://status.advanza.ai