Dokumentasie

Begin

Authagonal gee elke huurder 'n volledig standaard-voldoende OIDC-bediener. Elke huurder kry sy eie issuer URL, ontdekkingsdokument en token-eindpunte — geen gedeelde infrastruktuur tussen huurders nie. Jy kan binne 5 minute van niks na 'n werkende aanmeldvloei gaan.

Skep 'n Rekening

Registreer by authagonal.io en kies 'n slug vir jou rekening. Die slug word jou issuer-domein: {slug}.authagonal.io. Bevestig jou e-posadres nadat jy jou rekening geskep het.

Kies 'n unieke slug vir jou rekening tydens registrasie

Registreer 'n Client

Gaan na Clients in die portaalsy-kieslys en klik Skep. Voer 'n clientId en clientName vir jou toepassing in. Stel dan ten minste een redirect URI op — dit is waarheen gebruikers gestuur word na verifikasie. Byvoorbeeld: https://app.example.com/callback.

Registreer 'n nuwe OAuth client in die portaal

Jou Eerste Aanmelding

Die vinnigste manier om te integreer is met oidc-client-ts, 'n ligte OIDC-kliëntbiblioteek vir JavaScript- en TypeScript-toepassings.

import { UserManager } from 'oidc-client-ts';

const mgr = new UserManager({
  authority: 'https://acme.authagonal.io',
  client_id: 'my-app',
  redirect_uri: 'https://app.example.com/callback',
  response_type: 'code',
  scope: 'openid profile email',
});

// Redirect to login
mgr.signinRedirect();

// On callback page
const user = await mgr.signinRedirectCallback();
console.log(user.profile); // { sub, email, name, ... }

As jy 'n minimale benadering sonder 'n biblioteek verkies, kan jy die standaard OAuth 2.0 authorization code-vloei met gewone fetch gebruik:

// 1. Redirect the user to the authorization endpoint
const authorizeUrl = new URL('https://acme.authagonal.io/connect/authorize');
authorizeUrl.searchParams.set('client_id', 'my-app');
authorizeUrl.searchParams.set('redirect_uri', 'https://app.example.com/callback');
authorizeUrl.searchParams.set('response_type', 'code');
authorizeUrl.searchParams.set('scope', 'openid profile email');
authorizeUrl.searchParams.set('code_challenge', codeChallenge);
authorizeUrl.searchParams.set('code_challenge_method', 'S256');
window.location.href = authorizeUrl.toString();

// 2. On the callback page, exchange the code for tokens
const res = await fetch('https://acme.authagonal.io/connect/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: new URLSearchParams(window.location.search).get('code')!,
    redirect_uri: 'https://app.example.com/callback',
    client_id: 'my-app',
    code_verifier: codeVerifier,
  }),
});

const tokens = await res.json();
// tokens.id_token, tokens.access_token, tokens.refresh_token

Die verstekbladsy vir aanmelding vir jou huurder

Paneelbord

Die portaalpaneelbord gee jou 'n intydse oorsig van jou huurder. Dit toon die maatstawwe wat die meeste saak maak — gebruikersgroei, verifikasie-aktiwiteit en vinnige navigasie na elke funksie in die portaal.

Oorsig

Bo-aan die paneelbord sal jy 'n verwelkoming sien saam met jou huidige totale gebruikerstal. Daaronder toon 'n Daaglikse Aktiewe Gebruikers-grafiek 'n 7-dag-geskiedenis van unieke gebruikers wat elke dag aangemeld het, wat jou 'n vinnige pols op betrokkenheidsneigings gee.

Die paneelbordbladsy met DAU-grafiek en aktiwiteitsopsomming

Aktiwiteitsmaatstawwe

Die aktiwiteitsmaatstawwepaneel toon vier statistiekkaarte wat sleutel-verifikasiegebeurtenisse opsom:

• Suksesvolle Aanmeldings — totale voltooide verifikasievloeie
• Mislukte Aanmeldings — verkeerde bewyse, geslote rekeninge of beleidsverwerping
• Aktiewe Gebruikers — unieke gebruikers wat in die geselekteerde tydperk aangemeld het
• SCIM-bewerkings — gebruiker- en groepvoorsieningsgebeurtenisse van gekoppelde IdP's

Gebruik die tydsbestek-filters om te skakel tussen 24 uur, 3 dae, 7 dae en 30 dae. Alle statistiekkaarte en grafieke word bygewerk om die geselekteerde venster te weerspieël.

Aktiwiteitsmaatstawwe met instelbare tydsbestek

Vinnige Navigasie

Onder die maatstawwepaneel skakel navigasiekaarte direk na elke hooffunksie: Clients, Gebruikers, Groepe, Rolle, SSO, SCIM, Handelsmerke en Instellings. Elke kaart toon 'n kort beskrywing sodat nuwe spanlede vinnig kan oriënteer.

Clients

OAuth clients verteenwoordig die toepassings wat gebruikers deur jou huurder verifieer. Elke client het sy eie konfigurasie vir redirect URI's, scopes, grant types, token-lewenstye en MFA-beleid.

Clientlys

Die Clients-bladsy toon 'n tabel van alle geregistreerde clients. Elke ry toon die clientId, vertoonname, toegelate grant types as gekleurde kentekens, en of PKCE geaktiveer is. Klik enige ry om die volledige konfigurasie-redakteur oop te maak.

Clientlys met grant type-kentekens en PKCE-aanduiders

Skep 'n Client

Klik Skep Client om 'n nuwe toepassing te registreer. Jy moet twee velde verskaf:

• clientId — 'n unieke identifiseerder vir die client (bv. my-spa)
• clientName — 'n leesbare vertoonname

Registreer 'n nuwe OAuth client

Skrap 'n Client

Om 'n client te skrap, maak die clientkonfigurasie oop en klik die Skrap Client-knoppie onderaan die bladsy. Jy word gevra om te bevestig voordat die client permanent verwyder word. Alle aktiewe sessies en tokens vir die geskrapte client word onmiddellik ongeldig gemaak.

Clientkonfigurasie-verwysing

Elke client het 'n omvattende stel konfigurasiekeuses wat in verskeie afdelings georganiseer is.

Algemene Instellings

URI's

URI-velde gebruik 'n etiket-invoer — tik 'n waarde en druk Enter of komma om dit by te voeg. Klik die X op enige etiket om dit te verwyder.

Etiket-invoervelde vir die opstel van URI's

Scopes en Grant Types

Token-lewenstye

Stel token-lewenstye per client in

Afmelding-URI's

Clients kan beide agterkanaal- en voorkanaal-afmelding-URI's registreer. Enige of albei is opsioneel — stel op wat by hoe jou toepassing sy sessie verwyder pas.

MFA-beleid

Elke client kan die huurder-wye MFA-beleid met 'n per-client-instelling oorskry. Die MFA-beleid-aftreklys bied drie opsies:

Per-client MFA-beleidsoorskrywing

Enterprise SSO

Enterprise SSO laat u huurders hul eie identiteitsverskaffer bring. Authagonal ondersteun SAML 2.0 en OIDC-federasie met domeingebaseerde roering, sodat gebruikers outomaties na die korrekte IdP herlei word op grond van hul e-posadres.

Domeingebaseerde SSO-roering

SAML 2.0-verbindings

Om 'n SAML-verbinding te skep, navigeer na die SSO-bladsy en kies die SAML-oortjie. Verskaf die volgende:

Wanneer u die verbinding stoor, haal Authagonal die metadata-dokument op en voer die IdP se handtekeningsertifikaat, SSO-eindpunt-URL en naam-identifikasieformaat in. Die metadata word periodiek verfris om sertifikaatrotasies op te spoor.

Skep 'n SAML 2.0 SSO-verbinding

OIDC-verbindings

Om 'n OIDC-federasieverbinding te skep, kies die OIDC-oortjie en verskaf:

Skep 'n OIDC-federasieverbinding

Domeinroering

Domeinroering herlei gebruikers outomaties na die korrekte identiteitsverskaffer op grond van hul e-posdomein. Wanneer 'n gebruiker hul e-pos op die aanmeldingsbladsy invoer, kontroleer Authagonal of die domeingedeelte (bv. acme.com) met enige gekonfigureerde SSO-verbinding ooreenstem. As dit wel die geval is, word die gebruiker naatloos na hul organisasie se IdP herlei.

Domeinroering karteer e-posdomeins na identiteitsverskaffers

JIT-voorsiening

Standaard, wanneer 'n gebruiker vir die eerste keer via SSO aanmeld en nog nie in u huurder bestaan nie, skep Authagonal hul rekening outomaties (Just-In-Time-voorsiening). Dit kan per verbinding gedeaktiveer word deur Deaktiveer JIT-voorsiening te merk wanneer die verbinding geskep of gewysig word.

Wanneer JIT-voorsiening gedeaktiveer is, kan slegs gebruikers wat vooraf voorsien is — via SCIM, die portaal se Gebruikers-bladsy, of die API — deur dié verbinding aanmeld. Onbekende gebruikers ontvang 'n access_denied-fout en word versoek om hul administrateur te kontak.

Gebruikers

Die Gebruikers-bladsy laat u toe om alle eindgebruikers in u huurder te bestuur. U kan na gebruikers soek, hul besonderhede bekyk, nuwe rekeninge skep en sien hoe elke gebruiker voorsien is.

Soek en bladering

Die soekbalk ondersteun filtrering op e-posadres of gebruikers-ID. Soek word gedebons op 300ms sodat resultate opdateer soos u tik sonder om die API te oorweldig. Resultate is gepagineer op 50 gebruikers per bladsy — gebruik die navigasiebeheerders onderaan die tabel om tussen bladsye te beweeg.

Gebruikerstabel

Die gebruikerstabel vertoon die volgende kolomme vir elke gebruiker:

Die gebruikerslys met soekbalk en bladering

Gebruikers skep

Klik Skep gebruiker om 'n nuwe plaaslike gebruiker by te voeg. Die vorm vereis:

Skep 'n nuwe plaaslike gebruiker

Voorkeurstaal

Elke gebruiker het 'n voorkeurstaal wat hul gasheer-UI en die transaksiee-posse wat Authagonal hulle stuur aandryf (verifikasie, wagwoordterugstelling, verwelkoming en meer). U kan dit instel wanneer u 'n gebruiker skep en dit enige tyd van die gebruiker se besonderhede-bladsy verander. As 'n gebruiker geen voorkeurstaal het nie, val Authagonal terug op Engels. Die kieser bied alle ondersteunde tale: Engels, Duits, Frans, Spaans, Portugees, Viëtnamees en Vereenvoudigde Chinees.

Stel 'n gebruiker se voorkeurstaal in op die besonderhede-bladsy

Gebruikerbesonderhede

Klik enige ry in die gebruikerslys om die besonderhede-bladsy oop te maak. Van daar kan u profieldata wysig, rolle bestuur, MFA teruginstel, pasgemaakte eienskappe hersien en die gebruiker skrap.

Profiel

Wysig e-pos, voor-/van, telefoon, maatskappy, eksterne ID en skakel die gebruiker se aktiewe vlag. E-posveranderinge moet uniek bly binne die huurder; die API gee email_in_use terug indien beset.

Rolle

Ken rolle wat op die Rolle-bladsy gedefinieer is toe en herroep dit. Rol-lidmaatskap verskyn in ID- en access tokens wanneer die client includeRolesInTokens geaktiveer het.

Multi-faktor-outentisering

Sien elke MFA-geloofsbrief geregistreer vir die gebruiker — outentiseerder-app (TOTP), WebAuthn/toegangssleutels en herstelkodes — elk met sy eie geregistreerde/laas-gebruikte tydstempels. Verwyder individuele geloofsbriewe, of stel alle MFA terug. Teruginstelling dwing die gebruiker om by die volgende aanmelding opnuut te registreer.

Pasgemaakte eienskappe

Willekeurige sleutel/waarde-data geheg aan die gebruiker. Sleutels moet uniek wees. Eienskappe word blootgestel via die gebruikersprofiel-API en SCIM, en kan na access-token claims gekarteer word deur 'n pasgemaakte scope se userClaims te konfigureer.

Skrap gebruiker

Verwyder die gebruiker en al hul MFA-geloofsbriewe permanent. Tik die gebruiker se e-pos om te bevestig — dit kan nie ongedaan gemaak word nie.

Groepe

Groepe laat u toe om gebruikers te organiseer en groeplidmaatskap in tokens in te sluit. Groepe kan handmatig in die portaal geskep word of outomaties via SCIM uit 'n eksterne identiteitsverskaffer voorsien word.

Groeplys

Die Groepe-bladsy toon alle groepe in u huurder met die volgende inligting:

Groeplys met bronindikators

'n Groep skep

Klik Skep groep en voer 'n displayName vir die groep in. Groepname moet beskrywend en uniek wees binne u huurder (bv. "Engineering", "Billing Admins", "Beta Testers").

Groepbesonderhede en lede

Klik enige groep om die besonderhede-aansig oop te maak. Hier kan u alle huidige lede sien en lidmaatskap bestuur:

• Voeg lede by — Voer 'n gebruikers-ID in om 'n gebruiker by die groep te voeg.
• Verwyder lede — Klik die verwyderknoppie langs enige lid om hulle individueel te verwyder.

Bestuur groeplidmaatskap in die besonderhede-aansig

Groepe in tokens

Wanneer includeGroupsInTokens op 'n client geaktiveer is, sluit die ID token 'n groups claim in wat die gebruiker se groeplidmaatskappe bevat. Elke inskrywing sluit die groep se id en name in:

{
  "sub": "user-123",
  "email": "[email protected]",
  "groups": [
    { "id": "grp-001", "name": "Engineering" },
    { "id": "grp-002", "name": "Beta Testers" }
  ]
}

Rolle

Rolle ondersteun rolgebaseerde toegangsbeheer (RBAC) in u toepassing. Definieer rolle in Authagonal, wys dit aan gebruikers toe en gebruik die roles claim in tokens om magtiging in u toepassingslogika af te dwing.

Rolle bestuur

Die Rolle-bladsy vertoon 'n tabel van alle gedefinieerde rolle met inlyn-redigering. Elke rol het:

'n Rol skep

Klik Skep rol en verskaf 'n naam en beskrywing. Rolname moet bondig wees en 'n konsekwente naamkonvensie in u toepassing volg (bv. kleinletters met koppeltekens: billing-admin).

Inlyn-redigering

Rolle ondersteun inlyn-redigering direk in die tabel. Klik die potloodikoon op enige rol om wysigingsmodus te betree — die naam- en beskrywingsvelde word redigeerbaar. Verander die waardes en klik dan die regmerkikoon om te stoor. Veranderinge tree onmiddellik in werking.

'n Rol skrap

Klik die skrapikoon op enige rol om dit te verwyder. U sal gevra word om te bevestig voordat die rol permanent geskrap word. Die verwyder van 'n rol maak bestaande tokens nie terugwerkend ongeldig nie — die rol sal afwesig wees van nuwe tokens wat na skrapping uitgereik word.

Inlyn-redigering van rolle in die rollentabel

Rolle in tokens

Rolle wat aan 'n gebruiker toegewys is, word ingesluit as 'n roles claim in die ID token. U toepassing kan hierdie claim lees om magtigingsbesluite te neem:

{
  "sub": "user-123",
  "email": "[email protected]",
  "roles": ["admin", "billing-admin"]
}

SCIM Provisioning

SCIM 2.0 (System for Cross-domain Identity Management) maak outomatiese gebruiker- en groepinrigting moontlik vanaf ondernemingsidentiteitsverskaffers soos Okta, Azure AD, OneLogin en JumpCloud. Wanneer dit opgestel is, word gebruikersrekeninge en groeplidmaatskappe outomaties gesinkroniseer vanaf die stroomop-IdP na jou Authagonal-huurder.

SCIM-gebruikerslewensiklus-sinkronisasie met stroomaf-inrigting

Opstelstappe

Volg hierdie stappe om SCIM-inrigting vir 'n client te aktiveer:

1. Kies die client-toepassing — Kies die OAuth-client waaraan SCIM-inrigting gekoppel sal word.
2. Genereer 'n SCIM-token — Verskaf 'n beskrywing en 'n verstryktermyn in dae, en genereer dan die token.
3. Kopieer die token onmiddellik — Die rou token-waarde word slegs een keer vertoon. Kopieer dit voor jy die dialoog sluit.
4. Stel jou IdP op — In jou identiteitsverskaffer se SCIM-instellings, voer die basis-URL en bearer token in.
5. Toets gebruikersinkronisasie — Aktiveer 'n toetssinkronisasie vanuit jou IdP en verifieer dat gebruikers in die Authagonal-portaal verskyn.

SCIM-basis-URL

Stel jou identiteitsverskaffer op met die volgende basis-URL:

https://{slug}.authagonal.io/scim/v2

Vervang {slug} met jou huurder se slug.

SCIM-opstelbladsy met tokengenerering

Tokenbestuur

SCIM-tokens verifieer inrigtingversoeke vanaf jou IdP. Jy kan meerdere tokens per client bestuur:

Om 'n token te herroep, klik die Herroep-knoppie langs dit. Herroepte tokens bly in die lys sigbaar vir ouditeringsdoeleindes, maar stop onmiddellik om versoeke te aanvaar.

Tokenbestuur met aktiewe en herroepte tokenaanduidings

Konnektiwiteit Toets

Verifieer dat jou SCIM-integrasie werk deur die ServiceProviderConfig-endpoint te bevraagteken:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://acme.authagonal.io/scim/v2/ServiceProviderConfig

'n Suksesvolle respons gee 'n JSON-dokument terug wat die ondersteunde SCIM-funksies beskryf, insluitend massaoperasies, filtrering en wagwoordwysiging.

OAuth Scopes

Scopes laat clients toe om spesifieke dele van 'n gebruiker se data of toestemmings te versoek. Authagonal ondersteun beide standaard OIDC-scopes en pasgemaakte scopes wat jy vir jou API's definieer.

Ingeboude Scopes

Pasgemaakte Scopes

Definieer jou eie scopes op die Scopes-bladsy. Elke scope beskryf 'n toestemming of hulpbron wat 'n client kan versoek (byvoorbeeld billing.read, orders.write).

Pasgemaakte claims op tokens

Pasgemaakte claims het twee helftes. Die bron is per-gebruiker-data: elke AuthUser het 'n customAttributes-woordeboek wat jy kan bevolk vanaf die Portaal (Gebruikers → gebruiker → Pasgemaakte Attribute), via SCIM, of via 'n TCC-inrigtinghaak. Die vrystelling is per-scope: elke scope se userClaims-lys noem die sleutels wat dit toelaat om die bediener te verlaat.

Wanneer 'n client scopes versoek, deurstap Authagonal die toegestane scopes, voeg hul userClaims-lyste saam, en stuur slegs die sleutels van die gebruiker se customAttributes uit. Onbekende sleutels word stilweg gedroppeer — 'n client kan nie 'n attribuut lees deur die naam te raai nie. Standaard OIDC-claims (sub, email, name, ens.) volg die spesifikasie en is nie onderhewig aan die witlys nie.

# 1. On the user (Portal → Users → {user} → Custom Attributes)
department = "engineering"
employee_id = "E-1042"
seat_tier = "enterprise"

# 2. On a custom scope (Portal → Scopes → projects.read)
name        = "projects.read"
userClaims  = ["department", "seat_tier"]   # <-- whitelist

# 3. Client requests scope=openid projects.read
# Decoded access token (relevant fields only):
{
  "sub": "u-9b…",
  "scope": "openid projects.read",
  "department": "engineering",
  "seat_tier":  "enterprise"
  // employee_id is NOT emitted — it's not in the whitelist for any granted scope.
}

Scopes aan Clients Toewys

Voeg toegelate scopes by op die Clients → Scopes & Grants-oortjie. 'n Client kan slegs scopes versoek wat toegestaan is; onbekende scopes word verwerp met invalid_scope.

Handelsmerk

Pas die voorkoms van jou huurder se aanmeldbladsye aan. Handelsmerk-instellings laat jou toe om die verifikasie-ervaring op jou produk se visuele identiteit te stem — van logos en kleure tot gevorderde CSS-oorskrywings.

Voorkoms

Voorkoms-instellings met regstreekse kleurvoorskou

Kontakinligting

Aanmeldbladsywisselaars

Beheer watter elemente op jou huurder se aanmeldbladsy verskyn:

Voorbeeld aanmeldbladsy met pasgemaakte handelsmerk toegepas

Pasgemaakte CSS

Vir volle beheer oor die aanmeldbladsyvoorkoms, verskaf 'n CSS-lêer-URL in jou handelsmerk-instellings. Die lêer word na die verstekstyle gelaai, sodat jou reëls voorrang het.

Donkermodus

Die aanmeldtoepassing word gestuur met lig-, donker- en stelseltemplate. Gebruikers kies vanuit 'n wisselaar op die aanmeldbladsy; die keuse bly behoue oor sessies. Wanneer op system gestel, volg die SPA prefers-color-scheme regstreeks.

Ligwaardes word verklaar by :root; donker-oorskrywings is begrens na .dark. Huurder-handelsmerk ingestel via customCssUrl wen altyd — sodat jou kleure behoue bly ongeag die gebruiker se tema.

Instellings

Stel huurder-wye sekuriteitsbeleide, webhooks en omgewingsinstellings in. Hierdie instellings geld globaal vir alle clients, tensy op client-vlak oorskryf.

Wagwoordbeleid

Definieer die wagwoordkompleksiteitsvereistes vir alle gebruikers in jou huurder:

Wagwoordbeleid-konfigurasie

MFA-beleid

Die huurder-wye MFA-beleid stel die standaard multi-faktor-stawingsgedrag. Individuele clients kan hierdie instelling oorskryf.

Sessie en Uitsluit

Beheer sessieduur en rekeninguitsluitgedrag:

Sessie- en uitsluit-konfigurasie

Webhooks

Webhooks laat jou in reële tyd op stawingsgebeure reageer. Twee gebeure (onUserAuthenticated, onTokenIssued) is afdwingbaar — by verstek vuur hulle asinchronies en blokkeer nie die gebruiker nie, maar jy kan afdwinging per geleentheid aktiveer sodat 'n nie-2xx-respons of {"allow": false}-liggaam die aksie verwerp. Die oorblywende gebeure is kennisgewings — altyd brand-en-vergeet, blokkeer nooit.

Bykomende webhook-instellings:

Webhook-geleentheid-konfigurasie

Webhooks verifieer

Sodra enige webhook-URL opgestel is, munt Authagonal 'n per-huurder ondertekeninggeheim ('n whsec_… waarde wat slegs-leesbaar onder Instellings → Webhooks gewys word). Elke uitgaande aflewering dra 'n X-Authagonal-Signature: t=<unix>,v1=<hex>-opskrif, waar v1 HMAC-SHA256(secret, "{t}.{body}") is, bereken oor die rou versoekliggaam. Herbereken dit op jou eindpunt en vergelyk met konstante tyd om te bevestig die versoek het werklik van Authagonal gekom en nie gemanipuleer is nie — en verwerp afleveringe waarvan die t te oud is om herspeling te blokkeer.

import crypto from 'node:crypto';

// rawBody MUST be the exact bytes Authagonal sent — verify before any JSON re-serialization.
function verifyAuthagonalWebhook(signatureHeader, rawBody, signingSecret) {
  const parts = Object.fromEntries(signatureHeader.split(',').map((p) => p.split('=')));
  const { t, v1 } = parts;

  // Replay protection: reject deliveries older than 5 minutes.
  if (Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;

  const expected = crypto
    .createHmac('sha256', signingSecret)
    .update(`${t}.${rawBody}`)
    .digest('hex');

  return v1.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(v1), Buffer.from(expected));
}

Onderhoudvenster

Stel 'n voorkeur-onderhoudvenster in vir ontwrigtende bewerkings soos sertifikaatrotasies en infrastruktuurbywerkte. Kies 'n UTC-uur (0–23) — die portaal wys ook die ekwivalente tyd in jou plaaslike tydsone vir gemak.

Sandput-omgewing

Die sandput-omgewing is 'n volledige kloon van jou produksie-huurder, beskikbaar by 'n aparte URL. Gebruik dit om konfigurasiewysiging, SSO-integrasies en webhook-eindpunte te toets sonder om aktiewe gebruikers te beïnvloed.

Die sandput is toeganklik by {slug}-sandbox.authagonal.io.

Sandput-omgewingbeheer

Fakturering

Bestuur jou intekening en fakturering deur die portaal se Faktureringsbladsy. Hierdie bladsy gee jou 'n oorsig van jou huidige plan en bied toegang tot die Stripe-faktureringportaal vir die bestuur van betaalmetodes, fakture en planveranderings.

Intekenginligting

Die faktureringsbladsy toon jou huidige intekenbonderhede in 'n oogopslag. Jy sal 'n statuskenteken sien wat jou intekenstatus aandui — active, trialing, past_due, canceled of unpaid — saam met jou plannaam, die huidige faktureringstydperk (begin- en einddatums), en of jou intekening ingestel is om aan die einde van die huidige tydperk te kanselleer.

Bestuur Intekening

Klik die Bestuur Intekening-knoppie om die Stripe-faktureringportaal in 'n nuwe venster oop te maak. Van daar kan jy jou betaalmetodes werk by, fakture bekyk en aflaai, jou plan verander of jou intekening kanselleer.

As daar nog geen intekening bestaan nie, word 'n Stel Fakturering Op-aksie-oproep vertoon, wat jou deur die keuse van 'n plan en die invul van betalingsbesonderhede lei.

Die faktureringsbladsy toon jou huidige intekenbonderhede en bied toegang tot Stripe

Persoonlike Domeine

Bedien jou verifikasiebladsye vanaf jou eie domein (bv. auth.yourdomain.com) in plaas van die verstek {slug}.authagonal.io. Persoonlike domeine gee jou gebruikers 'n naatlose, handelsmerk-verifikasie-ervaring.

Voeg 'n Domein By

Voer die gasheernaam in wat jy wil gebruik in die domein-byvoegvorm (bv. auth.yourdomain.com). Sodra dit bygevoeg is, sal die domein in jou domeinlys verskyn met 'n pending_verification-status.

DNS-verifikasie

Skep 'n CNAME-rekord wat jou domein na {slug}.authagonal.io wys. Sodra die DNS-rekord in plek is, klik Verifieer om DNS-verspreiding te kontroleer.

auth.yourdomain.com.  CNAME  acme.authagonal.io.

TLS-sertifikate

Sodra jou domein geverifieer is, benodig jy 'n TLS-sertifikaat sodat gebruikers veilig via HTTPS kan koppel. Authagonal ondersteun twee opsies:

Outomaties (cert-manager) — Authagonal stel TLS-sertifikate outomaties in en hernu dit deur cert-manager. Dit is die aanbevole opsie vir die meeste gebruikers. Geen verdere konfigurasie is nodig nie.

Bring Jou Eie (BYO) — Laai jou eie sertifikaat en private sleutel in PEM-formaat op. Hierdie opsie is nuttig as jou organisasie sertifikate van 'n spesifieke sertifikaatowerheid vereis. Sertifikaatverval word nagespoor sodat jy voor die verloping kan hernu.

Domeinstatus

Elke domein toon 'n statuskenteken wat sy huidige toestand aandui: pending_verification (DNS nog nie bevestig nie), verified (DNS bevestig, TLS hangende), active (volledig operasioneel), of failed (konfigurasieprobleem opgespoor).

Die domeinlys toon elke persoonlike domein en sy huidige status

Laai jou eie TLS-sertifikaat en private sleutel in PEM-formaat op

E-poskonfigurasie

Stel in hoe jou huurder transaksionele e-posse stuur — verifikasie, wagwoordherstel en MFA-kennisgewings. Kies tussen die versteksender, 'n geverifieerde pasgemaakte domein via Resend, of jou eie SMTP-bediener.

Gelokaliseerde E-posse

Transaksionele e-posse word in die ontvanger se voorkeurtaal gestuur. Verifikasie-, wagwoordherstel-, rekening-bestaan-, verwelkoming-, fakturering- en admin-uitnodiging-e-posse is in sewe tale gesjabloneer: Engels, Duits, Frans, Spaans, Portugees, Viëtnamees en Vereenvoudigde Chinees. Wanneer geen sjabloon vir 'n ontvanger se taal bestaan nie, val die e-pos terug na Engels.

Die taal word opgelos uit die ontvanger se gestoorde voorkeur ten tyde van stuur. Hierdie voorkeur kan van verskeie plekke kom:

• Registrasie — vasgelê uit die taal wat die gebruiker op die aangebode aanmeldskenne gekies het.
• Die portaal-Gebruikersblad — gestel deur 'n admin by die skep of wysig van 'n gebruiker.
• SCIM-voorsiening — gekarteer uit die IdP se preferredLanguage wanneer gebruikers via SSO gesinkroniseer word.
• Die self-diens-rekeningbladsy — deur die gebruiker self gekies by /login/account.

E-posverskaffers

Stuurderidentiteit

Stuurder-e-pos en naam word gedeel oor alle verskaffer-modi. Stuurder-e-pos is vereis; stuurder naam val terug na die huurdernaam as dit leeg is.

Resend Pasgemaakte Domein

Verifieer jou stuurdomein met Resend eenmalig, gebruik dit dan as die Van-adres vir hierdie huurder. DNS TXT-rekords (SPF, DKIM) word deur die Domeine-bladsy verskaf; Resend valideer hulle outomaties.

Pasgemaakte SMTP

Bring jou eie SMTP-bediener — nuttig vir interne relais, verskaffers nie deur Resend gedek nie, of regulatoriese vaspen.

Pasgemaakte Stuurdomein

By gebruik van die Resend-verskaffer kan jy jou eie domein registreer sodat e-posse van jou handelsmerk kom (bv. [email protected]) in plaas van @authagonal.io.

1. Gaan na Instellings → E-pos en kies die Resend Pasgemaakte Domein-verskaffer.
2. Voer jou domeinnaam in en klik Registreer.
3. Voeg die getoonde DNS-rekords (DKIM, SPF en terugkeerpad) by jou domein se DNS.
4. Klik Kontroleer Verifikasie — sodra DNS versprei (gewoonlik 1–10 minute), verander die domeinstatus na geverifieer.

Toetsing

Gebruik die Stuur Toets-e-pos-knoppie in Instellings → E-pos om jou konfigurasie te verifieer. 'n Toets-e-pos sal na jou admin-e-posadres gestuur word met die huidige gestoorde instellings.

Ouditlys

Die Ouditlys bied 'n leesalleen-rekord van alle administratiewe aksies wat op u huurder uitgevoer is. Elke wysiging via die portaal of API word met volledige konteks vasgelê, sodat u 'n volledige spoor het vir nakoming en foutopsporing.

Lyskolonne

Gedopte Aksies

Die volgende administratiewe aksies word in die ouditlys aangeteken:

Die ouditlys bied 'n volledige rekord van alle administratiewe aksies

Rugsteun

Authagonal maak outomaties 'n rugsteun van jou huurderdata op 'n uurlikse skedule. Rugsteun sluit alle gebruikers, groepe, rolle, clients, SSO-verbindings, SCIM-tokens, handelsmerke en instellings in. Jy kan rugsteungeskiedenes bekyk en die jongste volledige rugsteun van die Rugsteunbladsy aflaai.

Hoe Rugsteun Werk

• Een volledige rugsteun loop daagliks en neem elke tabel in jou huurder se bergingsskakel.
• Inkrementele rugsteun loop uurliks en neem slegs rye wat sedert die laaste rugsteun verander het.
• Rugsteun word in Azure Blob Storage gestoor met dieselfde bestuurde identiteit as jou huurder.
• Geskrapte rekords word via grafsteen-rekords nagespoor en ingesluit in rugsteun vir oudit-volledigheid.

Rugsteun Aflaai

Klik Laai Jongste Af om 'n ZIP-leëer te kry wat die jongste volledige rugsteun saamgevoeg met alle daaropvolgende inkrementele rugsteun bevat. Elke tabel word as 'n JSONL-leëer uitgevoer (een JSON-objek per lyn).

Inrigtingsapps

Inrigtingsapps ontvang intydse webhook-kennisgewings wanneer gebruikers in u huurder geskep of geverifieer word. Dit stel stroomafwaartse stelsels in staat om outomaties rekeninge op te stel, lisensies toe te ken, of gebruikerdata te sinkroniseer sonder handmatige ingryping.

Hoe Dit Werk

Wanneer 'n gebruikersgebeurtenis plaasvind (skepping of verifikasie), skakel Authagonal u inrigtingsapp se terugbel-URL met die TCC (Try/Confirm/Cancel)-patroon. Hierdie drie-fase-benadering verseker betroubare inrigting oor verskeie stroomafwaartse stelsels:

Webhook-lading

Elke webhook-versoek bevat 'n JSON-lading met die volgende velde:

Voeg 'n Inrigtingsapp by

Om 'n inrigtingsapp by te voeg, verskaf 'n naam, 'n terugbel-URL, en 'n opsionele API-sleutel. Die API-sleutel word as 'n Bearer-token in die Authorization-opskrif van elke webhook-versoek gestuur, sodat u app versoeke van Authagonal kan verifieer.

Toetsing

Klik Toets langs enige inrigtingsapp om 'n toetsversoek na u terugbel-URL te stuur. Die toetsresultate wys die HTTP-statuskode en responliggaam, wat u help om te bevestig dat u app webhooks korrek ontvang en verwerk.

Toets inrigtingsapps om webhook-aflewering en responsverwerking te bevestig

Plan-perke

Die maksimum aantal inrigtingsapps is per huurder instelbaar, met 'n verstekgrens van 6. 'n Admin kan hierdie grens aanpas as u werkvloei addisionele inrigtingsteikens vereis.

Span

Die Spansbladsy bestuur portaaladmins — die mense wat jou huurder deur die bestuurportaal kan bereik en opstel. Alle spanlede het volle administratiewe toegang tot elke aspek van jou huurderopstelling.

Adminlys

Die adminlys toon elke spanlid se naam, e-posadres en die datum wat hulle bygevoeg is. 'n "Jy"-aanduider word langs die huidige gebruiker se ry getoon sodat jy jou eie rekening maklik kan identifiseer.

Admins Nooi

Om 'n nuwe spanlid te nooi, verskaf hul e-posadres, naam en 'n tydelike wagwoord (minimum 8 karakters). Die genodigde gebruiker meld aan met die tydelike wagwoord en moet dit by die eerste aanmelding verander.

Nooivelde

Admin-uitnodigings skep 'n volledig voorsiene gebruiker — geen e-pos-rondreis vereis nie.

Admins Verwyder

Klik Verwyder langs enige spanlid om hul toegang te herroep. 'n Bevestigingsdialoog word getoon voordat die verwydering gefinaliseer word. Jy kan jouself nie verwyder nie — daar moet altyd ten minste een admin in die span wees.

Bestuur portaaladmins vanaf die Spansbladsy

Ondersteuning

Maak 'n ondersteuningskaartjie oop by die Authagonal-span sonder om die portaal te verlaat. Elke kaartjie is 'n draadvormige gesprek, so jy en ons span bly op dieselfde bladsy van die eerste verslag tot oplossing.

Jou kaartjies

Die ondersteuningsbladsy lys elke kaartjie wat jy ingedien het, jongste aktiwiteit eerste. Gebruik die statuskenteken om in 'n oogopslag te sien wat op jou wag en wat op ons wag.

Jou ondersteuningskaartjies met onderwerp, status, prioriteit en laaste aktiwiteit

• Elke ry toon die onderwerp, huidige status (oop, hangende, opgelos of gesluit), prioriteit en tyd van die laaste aktiwiteit.
• Klik Nuwe kaartjie om een oop te maak, gee dit dan 'n onderwerp, prioriteit en jou eerste boodskap.
• Kleurgekodigde statuskentekens maak dit maklik om die lys te deurkyk vir kaartjies wat jou aandag benodig.

Kaartjiedraad

Die oopmaak van 'n kaartjie toon die volledige gesprek. Antwoorde word in volgorde geplaas, en nuwe boodskappe van ons span verskyn sonder 'n bladsyherlaai.

Kaartjiedraad tussen jou en die Authagonal-span

• Draadvormige boodskappe tussen jou en die Authagonal-span word in chronologiese volgorde getoon.
• Antwoord inlynig en heg leëers aan om logs, skermkiekies of konfigurasie te deel.
• Die draad word lewendig bygewerk, so 'n antwoord van ons span verskyn sodra dit gestuur is.
• As jy op 'n kennisgewing-e-pos antwoord, word jou boodskap outomaties ingedraad.

Invoer en migreer

Migreer 'n bestaande identiteitsstelsel na u Authagonal-huurder. Twee bronne word ondersteun — Duende IdentityServer ('n SQL Server-databasis) en Auth0 (die Management API). Elk laat 'n leesalleen-voorskou toe sodat u presies kan sien wat gekopieer sal word voordat u verbind.

Invoer vanaf Duende IdentityServer

Migreer clients, scopes, gebruikers en rolle vanaf 'n bestaande Duende IdentityServer SQL Server-databasis na u Authagonal-huurder. Die invoer loop in twee fases — voorskou en verbind — sodat u kan sien wat gekopieer sal word voordat enige wysigings gemaak word.

Wat Ingevoer Word

Die invoerder lees uit Duende se ConfigurationDb en ASP.NET Identity-tabelle en skryf gekarteerde rye na u huurder. Kortstondige artefakte soos aanhoudende toelatings, toestelkodes en ondertekeningssleutels word oorgeslaan.

Voorskou Voor Verbind

Plak u Duende ConfigurationDb / IdentityDb-verbindingstring en klik Voer voorskou uit. Die voorskou open 'n leesalleen-verbinding en tel elke ry wat ingevoer sou word — geen skryfwerk vind plaas nie.

• Entiteitstellings vir clients, scopes, gebruikers, rolle en roltoekennings.
• Oorskryf-waarskuwings wanneer die teikenhuurder reeds ooreenstemmende clients, rolle of scopes het.
• Waarskuwings vir onbekende tabelle en ongekartte kolomme sodat u weet watter data geskrap sal word.

Voorskoupaneel met tellings en waarskuwings

Wagwoordhasse

Duende stoor wagwoorde met ASP.NET Identity V3 (PBKDF2). Authagonal se PasswordHasher verifieer daardie formaat direk en herhash na die inheemse formaat by die eerste suksesvolle aanmelding — gebruikers behou hul bestaande wagwoorde sonder 'n hersettingsvloei.

Gebruiker-ID-rekonsiliasie

As 'n gebruiker wat reeds in hierdie huurder is dieselfde e-pos het as 'n inkomende rekord, roteer die invoer daardie rekening se userId na die bron-sub voor invoer, sodat die ingevoerde rolle, aanmeldings, en claims aan die bestaande rekening heg en toepassings wat die gebruiker reeds deur hul bron-sub verwys, bly oplos na die oorskakeling. Die rekening se bestaande wagwoord en profiel word behou; die bronrolle smelt bo-op saam. Die voorskou lys elke rekening wat gerekonsilieer sal word voordat u verbind.

Die Invoer Uitvoer

Klik Begin invoer nadat u die voorskou hersien het. Die verbindingsfase skryf clients, scopes, gebruikers, rolle en eksterne-aanmelding-verwysings na u huurder se stoor. Dubbele clientId-, scope name-, email- en role name-rye word oorgeslaan — die invoerder is veilig om te heruitvoer.

Wat Nie Ingevoer Word Nie

• Aanhoudende toelatings, toestelkodes, bediener-sessies — kortstondige artefakte, word outomaties hergenereer.
• Ondertekeningssleutels — Authagonal gee sy eie per-huurder-sleutels uit.
• Pasgemaakte kolomme en tabelle — alles buite Duende se standaardskema word as 'n waarskuwing aangedui sodat u weet die data is geskrap.
• Gedeaktiveerde clients — word in 'n gedeaktiveerde toestand ingevoer; heraktiveer hulle via die Clients-bladsy wanneer gereed.

Invoer vanaf Auth0

Koppel Authagonal aan u Auth0-huurder se Management API en bring u toepassings, API's, rolle, gebruikers en ondernemingsverbindings oor. Ingevoerde gebruiker- en toepassings-ID's word behou, sodat bestaande sub- en client_id-verwysings na die oorskakeling bly werk.

Wat u nodig het

Skep 'n Machine-to-Machine-toepassing in Auth0 wat gemagtig is vir die Management API, met hierdie leesscopes: read:users, read:clients, read:resource_servers, read:roles, read:connections, read:client_grants. Plak sy domein, client ID en client secret in die invoervorm — dit word slegs vir die invoer gebruik.

Wat Ingevoer Word

Wagwoorde

Auth0 se Management API gee nooit wagwoordhasse terug nie. As u Auth0 se ondersteuningsgeholpe massa-wagwoorduitvoer (NDJSON) het, verskaf dit — bcrypt-hasse word woordeliks ingevoer en u gebruikers behou hul wagwoorde sonder herinstel. Daardie lêer dra ook u volledige gebruikersstel, wat Auth0 se 1 000-gebruiker-API-lysgrens hef. Sonder dit word gebruikers as profiele ingevoer en stel 'n nuwe wagwoord by eerste aanmelding in.

API-verwysing

Elke huurder stel 'n standaard-voldoende OIDC-bediener bloot by https://{slug}.authagonal.io. Alle eindpunte volg die OAuth 2.0- en OpenID Connect-spesifikasies. Hierdie verwysing dek elke eindpunt waarmee u toepassing moontlik moet kommunikeer.

Magtigingskodestroom met PKCE

OIDC-ontdekking & JWKS

Die ontdekkingsdokument laat OIDC-kliëntbiblioteek toe om hulself outomaties te konfigureer. Geen verifikasie word vereis vir enige van die eindpunte nie.

GET /.well-known/openid-configuration

Gee die OpenID-aanbieder-konfigurasiedokument terug. Die respons bevat al die metadata wat u kliënt nodig het om met hierdie huurder te kommunikeer.

GET /.well-known/openid-configuration/jwks

Gee die JSON Web Key Set terug wat gebruik word om token-handtekeninge te verifieer. Die respons bevat 'n keys-reeks met RSA-publieke sleutels, elk met kty-, use-, kid-, alg-, n- en e-velde.

curl https://acme.authagonal.io/.well-known/openid-configuration

Magtigingseindpunt

GET /connect/authorize

Begin 'n magtigingskodestroom. Die gebruiker moet 'n aktiewe sessie hê, anders word hy aangestuur na die aanmeldblad. By sukses word die gebruiker teruggestuur na u toepassing met 'n magtigingskode.

Sukses-respons: 302-aanstuur na redirect_uri met code- en state-navraagparameters.

Fout-respons: 302-aanstuur met error-, error_description- en state-navraagparameters.

Pushed Authorization Requests (PAR)

RFC 9126. In plaas van om elke magtigingsparameter op die URL te plaas, POST u kliënt hulle na /connect/par met normale kliënt-verifikasie en ontvang 'n kortstondige, ondeursigtige request_uri terug. Die blaaier besoek dan /connect/authorize?client_id=...&request_uri=... — niks anders beland in die blaaier se geskiedenis, bedienerlêers, of Referer-opskrifte nie, en die bediener het reeds die parameters onder kliënt-verifikasie se integriteit nagegaan.

POST /connect/par

Kliënt-verifikasie is dieselfde as vir /connect/token: HTTP Basic met client_id/client_secret, of vorm-geënkodeerde geloofsbriewe. Publieke kliënte stuur sonder 'n secret. Die liggaam dra dieselfde parameters as wat u normaalweg na /connect/authorize sou stuur; request_uri self word verwerp (koppeling van 'n PAR word verbied deur §2.1 van die spesifikasie). Gee 201 Created terug.

Respons

By die opvolgversoek GET /connect/authorize?client_id=…&request_uri=… word alle ander parameters uit die gestuurde lading gehaal en enige ekstra navraagparameters word geïgnoreer. Die client_id op die magtigingsoproep moet ooreenstem met die kliënt wat die versoek gestuur het. Sodra dit gebruik is (of sodra expires_in verstreke is), word die request_uri uit die stoor verwyder.

# 1. Push parameters (server returns request_uri + expires_in)
curl -X POST https://acme.authagonal.io/connect/par \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "response_type=code" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "scope=openid profile email" \
  -d "state=$(openssl rand -hex 16)" \
  -d "code_challenge=YOUR_CODE_CHALLENGE" \
  -d "code_challenge_method=S256"

# 2. Send the user to /authorize with only client_id + request_uri
# https://acme.authagonal.io/connect/authorize?client_id=my-app&request_uri=urn:ietf:params:oauth:request_uri:abc123...

Token-eindpunt

POST /connect/token

Ruil geloofsbriewe vir tokens uit. Versoeke moet Content-Type: application/x-www-form-urlencoded gebruik. Kliënt-verifikasie kan verskaf word via HTTP Basic auth (Authorization: Basic base64(client_id:client_secret)) of as vorm-liggaam-parameters (client_id + client_secret).

Magtigingskode-subsidie

Refresh Token-subsidie

Client Credentials-subsidie

Toestelkode-subsidie

Token-respons:

curl -X POST https://acme.authagonal.io/connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "client_id=my-app" \
  -d "code_verifier=YOUR_CODE_VERIFIER"

UserInfo-eindpunt

GET /connect/userinfo

Gee claims oor die geverifieerde gebruiker terug. Vereis 'n geldige access token met die openid-scope.

curl https://acme.authagonal.io/connect/userinfo \
  -H "Authorization: Bearer ACCESS_TOKEN"

Token-inspeksie (RFC 7662)

POST /connect/introspect

Valideer 'n token en gee sy metadata terug. Vereis kliëntgeloofsbriewe (Basic auth of vorm-liggaam-parameters).

Aktiewe token-respons:

Onaktiewe token-respons: { "active": false }

curl -X POST https://acme.authagonal.io/connect/introspect \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "token=ACCESS_OR_REFRESH_TOKEN"

Token-herroeping (RFC 7009)

POST /connect/revocation

Herroep 'n voorheen uitgereike token. Vereis kliëntgeloofsbriewe.

Die eindpunt gee altyd 200 OK terug, selfs vir ongeldige of reeds herroepde tokens, ooreenkomstig die RFC 7009-spesifikasie.

Toestelmagtiging (RFC 8628)

POST /connect/deviceauthorization

Begin die toestelmagtigingstroom vir invoer-beperkte toestelle (CLI's, slim TV's, IoT-toestelle). Die toestel vertoon 'n kode aan die gebruiker, wat dan die versoek op 'n aparte toestel met 'n blaaier goedkeur.

Respons:

Goedkeuringstroom: Die gebruiker besoek die verification_uri, voer die user_code in en keur die versoek goed. Intussen peil die toestel die token-eindpunt met die device_code.

Peilings-foutkodes:

curl -X POST https://acme.authagonal.io/connect/deviceauthorization \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=my-cli" \
  -d "scope=openid profile email"

Sessie-beëindiging / Afmeld

GET POST /connect/endsession

Meld die huidige gebruikerssessie af, aktiveer back-channel logout na alle kliënte met 'n geregistreerde BackChannelLogoutUri, en herroep alle subsidies.

As 'n geldige post_logout_redirect_uri verskaf word en met 'n geregistreerde URI ooreenstem, ontvang die gebruiker 'n 302-aanstuur. Andersins bevestig 'n JSON-respons dat die sessie beëindig is.

SCIM 2.0 API-verwysing

Authagonal ondersteun die SCIM 2.0-protokol vir outomatiese gebruiker- en groepvoorsiening. Identiteitsverskaffer soos Okta, Azure AD en OneLogin kan hierdie API gebruik om jou Authagonal-huurder gesinkroniseer te hou met jou korporatiewe gids.

Basis-URL: https://{slug}.authagonal.io/scim/v2

Verifikasie: Alle versoeke vereis 'n Bearer-token. Genereer 'n SCIM-token in die portaal onder Instellings > SCIM-voorsiening.

Algemene opskrifte:

Lyseinpunte ondersteun bladering via startIndex (1-gebaseer) en count (maks. 200) navraagparameters, en filtrering via die filter-parameter (bv. userName eq "[email protected]").

Gebruikers

GET /scim/v2/Users — Lys gebruikers met opsionele bladering en filtrering.

GET /scim/v2/Users/{id} — Kry 'n enkele gebruiker aan die hand van hul Authagonal-gebruiker-ID.

POST /scim/v2/Users — Skep 'n nuwe gebruiker. Gee 201 Created terug.

PUT /scim/v2/Users/{id} — Volledige vervanging van 'n gebruikerhulpbron. Alle velde moet verskaf word.

PATCH /scim/v2/Users/{id} — Gedeeltelike opdatering via SCIM PatchOp.

DELETE /scim/v2/Users/{id} — Sagte skrap van die gebruiker (deaktiveer die rekening en herroep alle tokens). Gee 204 No Content terug.

curl -X POST https://acme.authagonal.io/scim/v2/Users \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "[email protected]",
    "name": {
      "givenName": "Jane",
      "familyName": "Smith"
    },
    "displayName": "Jane Smith",
    "active": true,
    "externalId": "ext-12345"
  }'

Groepe

GET /scim/v2/Groups — Lys alle groepe met opsionele bladering en filtrering.

GET /scim/v2/Groups/{id} — Kry 'n enkele groep aan die hand van ID, insluitend sy ledelist.

POST /scim/v2/Groups — Skep 'n nuwe groep. Gee 201 Created terug.

PUT /scim/v2/Groups/{id} — Volledige vervanging van 'n groephulpbron (insluitend sy ledelist).

PATCH /scim/v2/Groups/{id} — Gedeeltelike opdatering vir die byvoeging of verwydering van groepleede.

DELETE /scim/v2/Groups/{id} — Harde skrap van die groep. Gee 204 No Content terug.

curl -X PATCH https://acme.authagonal.io/scim/v2/Groups/GROUP_ID \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
      {
        "op": "add",
        "path": "members",
        "value": [
          { "value": "USER_ID_1" },
          { "value": "USER_ID_2" }
        ]
      }
    ]
  }'

Portal API (outomatisering)

Die Portal API laat jou eie agterkant toe om alles te outomatiseer wat jy in die portaal kan doen — bestuur gebruikers, clients, groepe, rolle, skope, SSO-verbindings en instellings — met 'n masjien-tot-masjien-geloofsbrief. Dit is dieselfde API wat die portaal-koppelvlak gebruik.

Basis-URL: https://portal-api.<your-domain>/api/v1. Versoeke verifieer met 'n Bearer access token; die huurder word uit die token geneem, nie die URL nie.

Skep 'n API-geloofsbrief

Maak in die portaal Clients → Skep API-geloofsbrief oop, kies 'n toegangsvlak en gee dit 'n naam. Authagonal genereer 'n OAuth client_credentials-client wat vir die Portal API opgestel is en gee 'n client-ID en -geheim terug.

Toegangsvlakke

Kry 'n token

Ruil die geloofsbrief vir 'n access token by jou huurder se token-eindpunt — https://<your-tenant>.<your-domain>/connect/token — en stuur dan die token as 'n Bearer-opskrif na die Portal API. Tokens is een uur geldig.

# 1. Exchange the credential for an access token (your tenant's token endpoint)
curl -X POST https://acme.authagonal.io/connect/token \
  -d grant_type=client_credentials \
  -d client_id=api-3f2a... \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d scope=tenant:admin

# Response: { "access_token": "ey...", "token_type": "Bearer", "expires_in": 3600 }

# 2. Call the Portal API with the access token
curl https://portal-api.authagonal.io/api/v1/users \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Eindpunte

Alle paaie is relatief tot die basis-URL en vereis 'n Bearer access token. Die skopus langs elke groep is die minimum geloofsbrief-toegangsvlak wat dit benodig. Lyseinpunte aanvaar startIndex- en count-navraagparameters.

GET/api/v1/clients— Lys OAuth-clients.

GET/api/v1/clients/{id}— Kry 'n enkele client aan die hand van ID.

POST/api/v1/clients— Skep 'n client. Gee die client-ID en, vir vertroulike clients, 'n eenmalige geheim terug.

PUT/api/v1/clients/{id}— Werk 'n client by (herleidings-URI's, toekenningtipes, token-lewensduur, PKCE/PAR-vereistes).

DELETE/api/v1/clients/{id}— Skrap 'n client.

POST/api/v1/clients/api-credential— Genereer 'n masjien-tot-masjien Portal API-geloofsbrief.

GET/api/v1/users— Lys gebruikers. Ondersteun startIndex, count en soek (e-pos / naamprefiks).

GET/api/v1/users/count— Totale gebruikertelling vir die huurder.

GET/api/v1/users/stats/mfa— MFA-inskrywingstatistieke.

GET/api/v1/users/{id}— Kry 'n enkele gebruiker.

POST/api/v1/users— Skep 'n gebruiker met 'n e-pos en wagwoord.

PUT/api/v1/users/{id}— Werk 'n gebruiker by (profiel, e-pos, geaktiveer/geblokkeer-toestand).

DELETE/api/v1/users/{id}— Skrap 'n gebruiker.

GET/api/v1/users/{id}/mfa— Get a user's enrolled MFA methods.

DELETE/api/v1/users/{id}/mfa— Reset a user's MFA enrollment.

GET/api/v1/roles— Lys rolle.

POST/api/v1/roles— Skep 'n rol.

DELETE/api/v1/roles/{id}— Skrap 'n rol.

POST/api/v1/roles/assign— Ken 'n rol aan 'n gebruiker toe.

POST/api/v1/roles/unassign— Verwyder 'n rol van 'n gebruiker.

GET/api/v1/groups— Lys groepe.

GET/api/v1/groups/{id}— Kry 'n groep met sy leede.

POST/api/v1/groups— Skep 'n groep.

POST/api/v1/groups/{id}/members— Voeg leede by 'n groep.

DELETE/api/v1/groups/{groupId}/members/{userId}— Verwyder 'n lid van 'n groep.

DELETE/api/v1/groups/{id}— Skrap 'n groep.

GET/api/v1/group-role-mappings— Lys groep-tot-rol-koppelinge (rolle wat by token-uitreiking deur groeplidmaatskap toegeken word).

GET/api/v1/scopes— Lys API-skope.

POST/api/v1/scopes— Skep 'n skopus.

DELETE/api/v1/scopes/{name}— Skrap 'n skopus.

GET/api/v1/saml/connections— Lys SAML-verbindings.

POST/api/v1/saml/connections— Skep 'n SAML-verbinding.

DELETE/api/v1/saml/connections/{id}— Skrap 'n SAML-verbinding.

GET/api/v1/oidc/connections— Lys OIDC-verbindings.

POST/api/v1/oidc/connections— Skep 'n OIDC-verbinding.

DELETE/api/v1/oidc/connections/{id}— Skrap 'n OIDC-verbinding.

GET/api/v1/sso/domains— Lys die domeine wat na SSO-verbindings geroeteer word (tuis-realmontdekking).

GET/api/v1/branding— Kry die huurder se handelsmerk (kleure, logo, ondersteunde tale).

PUT/api/v1/branding— Werk die huurder se handelsmerk by.

GET/api/v1/settings— Kry huurderinstellings (webhooks, openbare aanmelding, token-beleid).

PUT/api/v1/settings— Werk huurderinstellings by.

POST/api/v1/settings/webhook-secret/regenerate— Roteer die webhook-ondertekeningsgeheim.

POST/api/v1/settings/test-email— Stuur 'n toets-e-pos met die huidige e-poskonfigurasie.

GET/api/v1/custom-domains— Lys pasgemaakte aanmelddomeine en hul verifikasietatus.

POST/api/v1/custom-domains— Voeg 'n pasgemaakte domein by.

POST/api/v1/custom-domains/{domain}/verify— Begin DNS-verifikasie vir 'n pasgemaakte domein.

DELETE/api/v1/custom-domains/{domain}— Verwyder 'n pasgemaakte domein.

GET/api/v1/email/domains— Lys sender-e-posdomeine.

GET/api/v1/audit— Bevraagteken die huurder se ouditlog.

Voorbeeld: skep 'n gebruiker

curl -X POST https://portal-api.authagonal.io/api/v1/users \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "password": "S3cure-temp-passw0rd",
    "firstName": "Ada",
    "lastName": "Lovelace"
  }'

# 200 OK
# { "userId": "8f3a...", "email": "[email protected]" }

Aanmeldskerms

Dit is die aangebied skerms wat jou eindgebruikers op jou huurder se verifikasie-bediener sien. Authagonal lewer elke skerm gebruiksklaar, sodat jy 'n volledige, veilige aanmeld-ervaring kry sonder om enige koppelvlak te bou. Hierdie bladsy loop deur elke skerm en wys watter portaalinstellings dit beheer.

Aanmelding

• E-pos-eerste, tweestap-vloei: die gebruiker voer hul e-pos in en klik Gaan voort, dan verskyn die wagwoordveld.
• "Gaan voort met {provider}" enkelteken-op-knoppies verskyn outomaties wanneer SSO-verbindings bestaan.
• Wagwoord vergeet- en skep rekening-skakels, elk wat gewys of verberg kan word.
• Opsionele Cloudflare Turnstile-captcha om outomatiese aanmeldpogings te ontmoedig.

Beheer in die portaal-admin

• Branding stel die logo, kleur, app-naam, ondersteunings-e-pos en pasgemaakte CSS in.
• Wys of verberg die wagwoord-vergeet- en registrasie-skakels (Branding).
• SSO-verbindings voeg die sosiale aanmeldknoppies by (SSO-bladsy).
• Sessie-lewensduur en blokkeringsdrempelwaardes (Instellings → Sekuriteit).

Registrasie

• Versamel voor- en van (opsioneel), e-pos en 'n wagwoord.
• 'n Lewendige wagwoordbeleid-kontrolelys werk by soos die gebruiker tik, sodat vereistes duidelik is voor indiening.
• Opsionele Cloudflare Turnstile-captcha.
• 'n "Meld aan"-skakel vir gebruikers wat reeds 'n rekening het.

Beheer in die portaal-admin

• Wys of verberg die registrasie-skakel (Branding).
• Jou huurder se wagwoordbeleid dryf die kontrolelys.
• Branding stileer die hele skerm.

Wagwoord vergeet

• Die gebruiker voer hul e-pos in en sien dan 'n neutrale "kyk jou e-pos"-bevestiging.
• Die skerm onthul nooit of 'n rekening bestaan nie, wat rekeningopsomming-peiling verhinder.
• 'n "Terug na aanmelding"-skakel neem die gebruiker terug na die aanmeldskerm.

Beheer in die portaal-admin

• Wys of verberg die wagwoord-vergeet-skakel (Branding).
• Jou huurder se e-posaflewering stuur die herstellingsboodskap.
• Branding stileer die hele skerm.

Wagwoord herstel

• Nuwe wagwoord- en bevestig wagwoord-velde met 'n lewendige per-reël-vereistelys.
• 'n Duidelike ongeldige of verstreke skakel-toestand wanneer die herstel-token nie meer geldig is nie.
• 'n Sukses-toestand wat bevestig dat die wagwoord verander is.

Beheer in die portaal-admin

• Jou huurder se wagwoordbeleid dryf die kontrolelys.
• Branding stileer die hele skerm.

MFA-uitdaging

• 'n Metode-wisselaar tussen stawings-app, toegangssleutel en herstelkode.
• 'n 6-syfer TOTP-veld wat outomaties indien sodra alle syfers ingevoer is.
• Herstelkode-inskrywing vir gebruikers wat toegang tot hul stawer verloor het.
• 'n Toegangssleutel-knoppie vir hardeware-gesteunde verifikasie.

Beheer in die portaal-admin

• MFA-beleid word per toepassing ingestel (Clients → Sekuriteit).
• Enige gebruiker met 'n geregistreerde faktor word altyd uitgedaag, ongeag beleid.

MFA-opstelling

• Wys die status van geregistreerde metodes sodat die gebruiker weet wat reeds opgestel is.
• Stawer-opstelling via QR-kode, 'n handmatige sleutelalternatief en 'n bevestigingstap.
• Toegangssleutel-inskrywing vir hardeware-gesteunde stawing.
• Herstelkode-generering vir rekeningherstel.
• 'n Opsionele oorslaan wanneer MFA selfbedien eerder as vereis is.

Beheer in die portaal-admin

• MFA-beleid word per toepassing ingestel; Vereis dwing opstelling by aanmelding (Clients → Sekuriteit).
• Branding stileer die hele skerm.

Toestel-magtiging

• 'n Gesentreerde gebruikerskode-inskrywing-veld vir die kode wat op die toestel gewys word.
• 'n Goedkeur-stap om die toestel te magtig.
• 'n Aanmeld-tussenblad wanneer die gebruiker nog nie geverifieer is nie.
• 'n Goedgekeurde bevestiging sodra die toestel gemagtig is.

Beheer in die portaal-admin

• Aktiveer die toestelkode-grant op die toepassing (Clients → Grant types).
• Stel die toestelkode-lewensduur in (Clients → Tokens).

Toestemming

• Wys die versoekende client se logo en naam.
• 'n Per-scope-lys met gebruikersvriendelike, leesbare etikette vir elke toestemming.
• Toelaat- en Weier-knoppies om toegang toe te staan of te weier.
• 'n Toestemming-wenk-voetteks wat verduidelik wat die beslissing beteken.

Beheer in die portaal-admin

• Aktiveer Vereis toestemming per toepassing (Clients → Sekuriteit).
• Die logo, naam en URL kom van die toepassing se eie metadata.
• Branding stileer die toestemmingskaart.

Gekoppelde toepassings (grants)

• Lys elke toepassing wat die gebruiker gemagtig het, met sy naam, scopes en toestemmingsdatum.
• Herroep toegang tot 'n toepassing, met 'n bevestigingstap voordat dit van krag word.
• 'n Vriendelike leë toestand wanneer die gebruiker geen toepassings gemagtig het nie.

Beheer in die portaal-admin

• Die lys word gevul deur toestemming-vereiste toepassings.
• Branding stileer die hele skerm.

Rekening

'n Aangebied selfbediens-rekeningbladsy by /login/account waar aangemelde gebruikers hul eie profiel en voorkeurstaal bestuur, sonder portaaltoegang.

• Wysig voor- en van, maatskappy en telefoon; die e-posadres word leesalleen gewys.
• Kies 'n voorkeurstaal uit die ondersteunde lande; die koppelvlak voorskou die keuse onmiddellik en stoor dit by stoor.
• Die gestoorde taal dryf die gebruiker se aangebied koppelvlak en die taal van die transaksioneele e-posse wat hulle ontvang.

Beheer in die portaal-admin

• Branding stileer die hele skerm.
• Dieselfde voorkeurstaal is wysigbaar deur 'n admin op die portaal se Gebruikers-bladsy.

Stawingsvloeie

Stawingsvloeie dek hoe eindgebruikers met jou Authagonal-huurder kommunikeer — aanmeld, registreer, wagwoorde herstel en MFA opstel. Hierdie endpoints word gebruik deur die aangebied aanmeldbladsy en kan direk geroep word as jy 'n pasgemaakte aanmeld-koppelvlak bou.

Aanmelding

POST /api/auth/login

Staaf 'n gebruiker met e-pos en wagwoord. By sukses, teken 'n sessie-cookie en gee die gebruikersprofiel terug. As MFA opgestel is, dui die respons aan dat 'n tweede faktor vereis word voordat die sessie ten volle tot stand gekom het.

Versoekliggaam:

{
  "email": "[email protected]",
  "password": "correct-horse-battery-staple"
}

Sukses-respons:

MFA-vereiste respons: Wanneer die gebruiker MFA geregistreer het, sluit die respons mfaRequired: true in saam met 'n challengeId en 'n methods-skikking wat beskikbare MFA-metodes lys.

MFA-opstelling vereiste respons: Wanneer die huurder MFA vereis maar die gebruiker nog nie geregistreer het nie, sluit die respons mfaSetupRequired: true in met 'n setupToken vir die registrasie-vloei.

Fout-responsies:

SSO-kontrole: As die gebruiker se e-posdomein 'n SSO-verbinding opgestel het, gee die aanmeld-endpoint sso_required terug met 'n redirectUrl. Die client moet die gebruiker na die SSO-verskaffer herlei.

Rekening-blokkering: Na maxFailedAttempts agtereenvolgende mislukte aanmeldpogings, word die rekening gesluit vir lockoutDurationMinutes. Beide waardes is instelbaar in huurder-instellings.

Registrasie

POST /api/auth/register

Skep 'n nuwe gebruikersrekening. 'n Verifikasie-e-pos word outomaties gestuur — die gebruiker moet hul e-pos verifieer voordat hulle kan aanmeld.

Versoekliggaam:

{
  "email": "[email protected]",
  "password": "a-strong-password-here",
  "firstName": "Jane",
  "lastName": "Smith"
}

Sukses: 201 Geskep met die userId van die nuwe rekening. Registreer met 'n e-pos wat reeds gebruik word, gee ook 201 terug: ons onthul nooit of 'n e-pos bestaan nie (om rekeningopsomming te verhinder), en stel eerder die werklike rekeninghouer per e-pos in kennis.

Fout-responsies:

Wagwoordherstel

POST /api/auth/forgot-password

Versoek 'n wagwoordherstel-e-pos. Die endpoint gee altyd 'n sukses-respons terug, ongeag of die e-pos bestaan, om e-posopsomming te verhinder.

{
  "email": "[email protected]"
}

POST /api/auth/reset-password

Herstel die gebruiker se wagwoord met behulp van die token uit die e-pos-skakel.

{
  "token": "RESET_TOKEN_FROM_EMAIL",
  "newPassword": "new-strong-password"
}

Newe-effekte van 'n suksesvolle wagwoordherstel:

• Mislukte aanmeldpoging-teller word na nul herstel
• Alle bestaande refresh tokens word herroep
• 'n Nuwe sekuriteitstempel word gegenereer (wat alle bestaande sessies ongeldig maak)

MFA-opstelling en -verifikasie

Authagonal ondersteun drie MFA-metodes: TOTP (stawings-apps), WebAuthn (sekuriteitssleutels en biometrie) en enkelmaal-herstelkodes.

TOTP-opstelling

POST /api/auth/mfa/totp/setup — Gee 'n QR-kode-data-URI en 'n handmatige invoersleutel terug. Die gebruiker skandeer die QR-kode met hul stawings-app (Google Authenticator, Authy, 1Password, ens.), en bevestig dan inskrywing.

POST /api/auth/mfa/totp/confirm — Bevestig TOTP-inskrywing deur 'n 6-syfer-kode van die stawings-app te valideer.

{
  "code": "123456"
}

WebAuthn-opstelling

POST /api/auth/mfa/webauthn/setup — Gee geloofsbrief-skeppingsopsies vir die WebAuthn API terug. Die blaaier roep navigator.credentials.create() met hierdie opsies.

POST /api/auth/mfa/webauthn/confirm — Bevestig WebAuthn-inskrywing deur die bevestigingsrespons van die blaaier in te dien.

Herstelkodes

POST /api/auth/mfa/recovery/generate — Genereer 10 enkelmaal-gebruikbare 8-karakter-herstelkodes. Elke kode kan presies een keer gebruik word om MFA te omseil.

MFA-verifikasie

POST /api/auth/mfa/verify — Voltooi die MFA-uitdaging na 'n suksesvolle wagwoord-aanmelding.

MFA-status

GET /api/auth/mfa/status — Gee die gebruiker se tans geregistreerde MFA-metodes terug.

SSO-aanmeld-vloei

Authagonal ondersteun beide SAML 2.0 en OIDC-gebaseerde SSO-verbindings. Domein-gebaseerde roeteplanning speur outomaties watter SSO-verskaffer gebruik moet word op grond van die gebruiker se e-posadres.

SSO-kontrole

GET /api/auth/[email protected]

SAML-vloei

Die gebruiker word herlei na GET /saml/{connectionId}/login wat 'n SAML AuthnRequest na die identiteitsverskaffer stuur. Die IdP staaf die gebruiker en plaas 'n SAML-respons terug na die Assertion Consumer Service (ACS) endpoint. Authagonal valideer die bewering, skep of werk die gebruiker by, en teken 'n sessie-cookie.

SAML-metadata vir die opstelling van jou IdP is beskikbaar by GET /saml/{connectionId}/metadata.

OIDC-vloei

Die gebruiker word herlei na GET /oidc/{connectionId}/login wat na die boontoe identiteitsverskaffer herlei met PKCE. Nadat die gebruiker gestaaf het, ruil die callback by /oidc/callback die magtigingskode in, valideer die ID token en skep of werk die gebruiker by.

JIT-voorsiening: Beide SAML- en OIDC-vloeie ondersteun just-in-time-voorsiening. As die gebruiker nog nie in die huurder bestaan nie, word hulle outomaties geskep uit die identiteitsverskaffer se claims. As hulle wel bestaan, word hul profieleienskappe opgedateer om die nuutste waardes van die verskaffer te weerspieël.

Bou 'n pasgemaakte aanmeld-UI

Vervang Authagonal se aangebode aanmeld-, registrasie-, wagwoordherstel- en MFA-skerms met jou eie UI, terwyl Authagonal steeds stawing, MFA, SSO, sessies en token-uitreiking hanteer. Twee opsies: gebruik ons React-komponentbiblioteek, of roep die auth API direk vanuit enige raamwerk. Dit is opt-in — aktiveer eers Pasgemaakte aanmeld-UI in huurder-instellings.

Vereiste: 'n pasgemaakte domein op jou wortel

Die aanmeldsessie is 'n eerste-party-koekie, sodat jou UI en die Authagonal-auth-bediener 'n registreerbare domein moet deel. Wys 'n pasgemaakte auth-domein na Authagonal op dieselfde wortel as jou toepassing — bv. auth by login.acme.com, toepassing by app.acme.com. Die Pasgemaakte aanmeld-UI-instelling bly gedeaktiveer totdat 'n aktiewe pasgemaakte domein bestaan.

Voeg ook jou UI se oorsprong (bv. https://app.acme.com) by jou OAuth-client se Toegelate CORS-oorspronge — dieselfde lys wat jy vir die token-uitruiling stel.

React: @authagonal/login

npm i @authagonal/login lewer die auth-logika en UI as een pakket — dieselfde as waarop Authagonal se aangebode aanmelding gebou is. Kies jou vlak:

• Volledige toepassing — sit App in en temeer dit via handelsmerking.
• Stel bladsye saam — gebruik LoginPage, MfaChallengePage, ResetPasswordPage… binne jou eie uitleg.
• Primitiewe + logika — bou jou eie skerms met AuthLayout/Button/Input en die API-kliënt (login, mfaVerify, forgotPassword, …).

import { AuthLayout, Input, Button, login, ApiRequestError } from '@authagonal/login';

function MyLogin() {
  async function onSubmit(email: string, password: string) {
    try {
      const res = await login({ email, password });        // POST /login (sets the session cookie)
      if (res.mfaRequired) {/* render your MFA step → mfaVerify(...) */}
      else window.location.href = res.returnUrl;            // hand off to /connect/authorize
    } catch (e) {
      if (e instanceof ApiRequestError) {/* show e.message */}
    }
  }
  return <AuthLayout>{/* your own markup + <Input/> <Button/> */}</AuthLayout>;
}

Enige raamwerk: roep die auth API

Nie op React nie? Roep die auth-vloei-eindpunte direk (onder /api/auth), gee dan oor aan die standaard OIDC /connect/authorize-vloei. Stuur credentials: 'include' sodat die sessiekoekie gestoor word.

# 1. Authenticate (browser fetch — credentials:'include' so the session cookie is stored)
curl -i -X POST https://login.acme.com/api/auth/login \
  -H "Content-Type: application/json" \
  -H "Origin: https://app.acme.com" \
  --data '{"email":"[email protected]","password":"..."}'
# (handle {"mfaRequired":true} → POST /api/auth/mfa/verify, then continue)

# 2. Hand off to the OAuth flow — top-level navigation to the authorize endpoint with PKCE:
# https://login.acme.com/connect/authorize?client_id=my-app&redirect_uri=...&response_type=code
#   &scope=openid%20profile%20email&code_challenge=...&code_challenge_method=S256
# The session cookie (same-site) authenticates the user; you get back a code → exchange at /connect/token.

Planne & Limiete

Authagonal bied vier plantrae aan. Alle planne sluit alle funksies in — die enigste verskil is die Maandelikse Aktiewe Gebruiker (MAU)-limiet en oorskrydingsprysing.

Plantrae

Maandelikse Aktiewe Gebruikers (MAU)

'n Maandelikse Aktiewe Gebruiker is enige unieke gebruiker wat minstens een keer suksesvol verifieer tydens 'n faktureringsmaand. Gebruikers wat via SCIM voorsien is maar nie aangemeld het nie, tel nie teen jou MAU-totaal nie.

Oorskryding — As jou plan oorskryding ondersteun, word gebruikers bo die MAU-limiet gefaktureer teen die per-gebruiker-tarief in die plantabel hierbo. Jy kan 'n oorskrydingsgrens instel om jou maksimum besteding vir die faktureringstydperk te beperk.

Handhawing — As jou plan nie oorskryding ondersteun nie (Starter), kan gebruikers bo die MAU-limiet nie aanmeld nie totdat die volgende faktureringstydperk begin of jy opgradeer na 'n plan wat oorskryding ondersteun.