Ö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-IDredirect_uri(obligatorisk): URL att omdirigera till efter autentiseringresponse_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 challengecode_challenge_method(obligatorisk tillsammans med code_challenge): 'S256'state(rekommenderas): Slumpmässig sträng för att förhindra CSRF-attackertenant_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 /authorizeclient_id(obligatorisk): Ditt applikations-IDclient_secret(obligatorisk): Din applikationshemlighet (håll konfidentiell)redirect_uri(obligatorisk): Måste matcha /authorize-anropetcode_verifier(obligatorisk för SPA): PKCE code verifierrefresh_token(för refresh-flöde): Refresh token som ska bytas utusername & 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.)
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-postadressemail_verified: Om e-posten är verifieradname, given_name, family_name: Användarens namntenant_id: Användarens aktiva tenant/organisationiss: 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-IDemail, name: Användarinformationtenant_id: Aktiv tenant (används för multi-tenancy-routning)roles: Användarens roller i tenantenscope: Beviljade scopesexp: 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