Authentification et autorisation

Une boucle AuthN/AuthZ robuste est un point de vérité unique sur qui vous êtes (authentification) et ce que vous êtes autorisé (autorisation). Dans une plate-forme avec de nombreuses marques, régions, intégrations et exigences réglementaires élevées, ce circuit doit être modulaire, observable et géré par des politiciens, plutôt que de « mettre des if sur les services ».

1) Termes de base et rôles

Identification (ID) : Identification (utilisateur, service, fournisseur).
Authentification (AuthN) : preuve d'identité (mot de passe, MFA, certificat).
Autorisation (AuthZ) : Prendre une décision « possible/impossible » en fonction des politiques et du contexte.
PDP/PEP : Policy Decision Point (prend une décision )/Policy Enforcement Point (applique).
IdP : Fournisseur d'identification (OIDC).
Subject/Resource/Action/Context : qui/à quoi/ce qu'il fait/dans quelles conditions.

2) Architecture de contour générale

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Principes : centralisation de la génération de tokens et de politiques, application locale ; « privilèges minimaux » et délégations explicites.

3) Authentification des utilisateurs (OIDC/OAuth 2. 1)

• Code d'autorisation + PKCE (toujours pour SPA/Mobile).
• SSO : support de l'IdP externe (SAML/OIDC) pour b2b/opérateurs.
• MFA : TOTP/WebAuthn/SMS (recommandé par WebAuthn et TOTP ; SMS — fallback).
• Risk-based Step-Up : pour les actions sensibles (retrait, modification des détails), exiger un MFA/pe-Auth.

• Refresh Token Rotation + registre RT avec un détecteur de réutilisation.
• Nonce/State + PKCE, le CORS/CSRF strict pour les flux de navigateur.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) pour les opérations critiques.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Service d'authentification (mTLS, SPIFFE, JWT)

mTLS entre les services + SPIFFE/SPIRE pour les identifiants workload's durables.
Service JWT avec une courte durée (≤5 min) signée par HSM/KMS ; audit de l'émission.
Audience-scoped : JWT ne convient qu'à un service/domaine particulier.
Zones de confiance : services d'une autre région/tenante - ICP et politiques distinctes.

5) Modèles d'autorisation : RBAC, ABAC, ReBAC

RBAC (rôles de résolution →) : simple et transparent (adapté aux panneaux admin, opérateurs).
ABAC (attributs sujet/ressource/contexte) : flexible pour les règles "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (relations) : utile pour les exploitations complexes (« qui possède une marque/un dossier/une campagne »).

Recommandation : hybride - RBAC de base + conditions ABAC contextuelles + relations ReBAC ponctuelles.

6) Politiques et leur exécution (PDP/PEP)

PEP sur Gateway et dans les services : extrait le contexte (JWT, mandats, IP/ASN, heure, région, niveau KYC), forme une requête vers le PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

et renvoie 'ALLOW/DENY' + explication.

Le cache de solutions de PEP (TTL 30-120 c) réduit la latence ; invalidité par les événements « changement de rôle/politique ».

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Scoops et permis

• Ressource : l'action est 'wallet : read', 'wallet : transfer', 'bets : place', 'kyc : status. read`.
• Pour les admins - 'admin :' dans un domaine isolé.
• Pour les fournisseurs - 'provider : report. read`, `provider:events. push`.

Le principe des privilèges minimums : nous ne nommons que les bons scoops ; « escalade » (extensions temporaires des droits) - par tiquet et avec TTL.

8) Multi-tenants et régions (résidence)

Les tokens contiennent 'tenant', 'region', 'licence' ; Le PDP vérifie la conformité de la ressource.
Rôles/politiques - espaces de noms per tenant ('role : brand _ eu/support').
Diviser les clés de signature et les listes de révocation par région ; demandes croisées régionales - uniquement via des passerelles de confiance.

9) Gestion des sessions et des appareils

Server-side session store pour le Web (ancrage au périphérique/navigateur, rotation de l'ID).
Idle/Absolute Timeout (par exemple, 30 min/24 h) ; les actions sensibles sont re-Auth/MFA.
Liste des dispositifs actifs, « sortie de tous ».
Anomalies : entrées simultanées de différentes régions, échecs fréquents de MFA - signaux de risque.

10) Délégation et consentement (consent)

On-behalf-of (OBO) : le service agit au nom de l'utilisateur (token proxy avec 'sub '/' act' séparé).
Consentement : écran explicite pour l'accès des partenaires aux données, journal des consentements à la révocation.
Accès-mandats temporaires : Droits sur N heures/jours, expirant automatiquement.

11) Clés, signatures et rotation

JWKS avec 'kid', rotation automatique, stockage de clés privées dans KMS/HSM.
Algorithmes : ES256/EdDSA pour JWT ; TLS 1. 2+/mTLS.
Période Dual-key : Acceptez les deux 'kid' avant la mise à jour des clients.
Rappel de RT et Token Introduction pour les incidents critiques.

12) Sécurité des applications client

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile : App Attestation/Device Check, stockage RT sécurisé, protection ruth/jailbreak.
Desktop : navigateur système pour login (no embedded web-views), PKCE.

13) Contrats SDK commodes

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) Observation et audit

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• Anomalies d'entrée (nouveau périphérique, géo-velocity), scoops suspects.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Exportation pour la conformité (régulateur/vérificateur).

15) Protection du périmètre et du client

Gateway PEP : rate-limit, bot/signature checks, protection CSRF, stricte CORS, HSTS.
Trafic interne : mTLS + services JWT + réseaux limités.
Webhooks/collbacks externes : signatures du corps (HMAC/JWS), fenêtres temporelles, anti-réplication.

16) Erreurs typiques

Jetons d'accès à longue durée de vie → fuites.
Flux implicite OAuth dans le SPA.
Pas de rotation de clé et de période Dual-Key.
Rôles zachardköned au lieu de politiques (impossible d'auditer/expliquer les décisions).
Mélange de tenants/régions dans un seul 'role' ou 'key'.
Pas de step-up MFA sur les actions sensibles.
Cache des solutions AuthZ sans handicap par changement de rôle.

17) Pleybooks (runbooks)

1. Compromis de la clé de signature JWT

Revoke immédiat 'kid', publication du nouveau JWKS, séances de RT/invalidation forcée, rapport d'audit.

2. Masse 'invalid _ token'

Vérifiez l'horloge/la durée de vie, la pertinence de JWKS, les pannes de cache.

3. Anomalies des entrées

Activer le risque élevé, exiger step-up, avertir l'utilisateur, limiter temporairement les paiements.

4. Échec de l'IdP

Passer au cache de session/machine de rôle, limiter les nouveaux logins, maintenir les sessions en cours jusqu'à TTL.

18) Chèque-liste avant la vente

• OIDC/OAuth 2. 1 avec PKCE, court AT, rotation RT, binding de device pour les opérations critiques.
• MFA (WebAuthn/TOTP) et step-up pour les conclusions/changements de détails/rôle-escalade.
• Service-to-service : mTLS + SPIFFE, JWT de service à courte durée de vie.
• Politiques AuthZ (RBAC + ABAC/ReBAC) dans le PDP centralisé ; PEP sur gateway et dans les services.
• Cache des décisions concernant les personnes handicapées ; la piste d'audit est immuable.
• Multi-tenants/régions : isolation des clés/politiques/logs, comptabilité des licences.
• JWKS/clés dans KMS/HSM, rotation à double clé, surveillance 'kid'.
• CSRF/CORS/HSTS/Rate-limit/bot filtres sur le périmètre.
• Pleybooks incidents, run-boutons revoke/rotate/lockdown.
• Ensemble de tests : unité (politiques), contrat (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini modèles de configuration

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

Conclusion

La boucle d'authentification et d'autorisation n'est pas une bibliothèque, mais une capacité de plateforme : jetons à courte durée de vie et clés gérables, politiques centralisées et leur application locale, multifacteur et step-up, isolement strict des tenants/régions, audit et télémétrie. Cette conception rend les changements sûrs, compréhensibles pour le régulateur et transparents pour le produit - et l'échelle sur les marchés et les équipes devient une opération de routine plutôt qu'un exploit.