authicto
Identity provider · 2026
Identity provider · 2026
Sovereign hosting — Morocco
Hébergement souverain — Maroc
OIDC · PKCE S256 Multi-tenant v1.0

authicto

The OIDC identity provider for applications built in Morocco. Le OIDC identity provider pour les applications conçues au Maroc.

Identity is the one problem you cannot half-solve. authicto takes that weight off the product team — sovereign hosting, three standard HTTP calls, certified against the Moroccan standards that actually get enforced. L'identité est le problème qu'on ne peut pas résoudre à moitié. authicto en décharge l'équipe produit — hébergement souverain, trois appels HTTP standard, certifié contre les textes marocains qui s'appliquent réellement.

ProtocolProtocole OIDC Authorization Code
Proof of keyPreuve de clé PKCE · S256
Assurance levelsNiveaux d'assurance Standard · High (TOTP) · CNIE-ready Standard · Élevé (TOTP) · CNIE-ready
TenancyMulti-tenant One provider, N products Un provider, N produits

Built for teams who ship to real users. Conçu pour les équipes qui livrent à de vrais utilisateurs.

If your product touches a patient record, a bank account, a tax form, or any data worth protecting — identity is the first line of defence. authicto is that line. Si votre produit touche un dossier patient, un compte bancaire, un formulaire fiscal, ou toute donnée qui mérite protection — l'identité est la première ligne de défense. authicto est cette ligne.

Healthtech Healthtech

Patient portals. Practitioner consoles.

Portails patients. Consoles praticiens.

Any interface that touches a medical record carries a legal weight most product teams are not equipped to absorb. authicto absorbs it.

Toute interface qui touche à un dossier médical porte un poids juridique que la plupart des équipes produit ne sont pas équipées pour absorber. authicto l'absorbe.

→ Medictom uses authicto to gate access to consultation records and prescription histories.
→ Medictom utilise authicto pour contrôler l'accès aux dossiers de consultation et d'ordonnances.
Fintech · GovTech Fintech · GovTech

Where assurance of identity is the product.

Là où le niveau d'assurance d'identité fait le produit.

Citizen-facing services that cannot accept a forged login. Before a sensitive operation, authicto can require a second factor — a one-time code from an authenticator app — without a full re-login.

Services au citoyen qui ne peuvent pas accepter un login falsifié. Avant une opération sensible, authicto peut exiger un second facteur — un code à usage unique depuis une application d'authentification — sans re-login complet.

→ Bank transfers, fiscal declarations, CNIE-backed authentication.
→ Virements bancaires, déclarations fiscales, authentification adossée à la CNIE.
Multi-tenant SaaS SaaS multi-tenant

Enterprise SSO on day one.

SSO entreprise dès le premier jour.

B2B applications whose first enterprise customer asks for SSO — and doesn't accept "it's on the roadmap". authicto is the answer that ships today.

Applications B2B dont le premier client entreprise demande du SSO — et n'accepte pas « c'est dans la roadmap ». authicto est la réponse qui est livrable aujourd'hui.

→ One config entry per tenant. Separate secrets. Separate redirect URIs.
→ Une entrée de config par tenant. Secrets séparés. Redirect URIs séparés.

authicto owns identity. Your app owns authorization. authicto possède l'identité. Votre application possède l'authorization.

The cleanest separation in modern application architecture — and the one most teams get wrong. Once the boundary is clear, everything downstream becomes easier to reason about, audit, and evolve. La séparation la plus nette de l'architecture applicative moderne — et celle que la plupart des équipes ratent. Une fois la frontière posée, tout ce qui suit devient plus simple à raisonner, à auditer, et à faire évoluer.

Identity layer Couche identity

authicto handles

authicto se charge de

  • Identity proofing Identity proofing Password + TOTP MFA live today. CNIE chip-backed assertions via a pluggable backend — DGSN/ADD SDK drops in on release. Password + TOTP MFA opérationnels aujourd'hui. Assertions adossées à la puce CNIE via un backend pluggable — le SDK DGSN/ADD s'intègre dès sa sortie.
  • Authentication & step-up Authentication & step-up Standard assurance for ordinary access, MFA-backed high assurance for sensitive operations — no full re-login required. Assurance standard pour l'accès ordinaire, assurance élevée avec MFA pour les opérations sensibles — pas de re-login complet.
  • Session security Sécurité de session HttpOnly cookies, version counter, idle + absolute TTL, revocation fan-out. Cookies HttpOnly, compteur de version, TTL idle + absolu, fan-out de révocation.
  • Consent capture Capture du consentement Timestamped, versioned, revocable — and enforced at the token boundary. Horodaté, versionné, révocable — et appliqué à la frontière du token.
  • Audit log Journal d'audit INSERT-only at the database, mirrored to SIEM, non-repudiable by construction. INSERT-only au niveau base, miroir SIEM, non-répudiable par construction.
Authorization layer Couche authorization

Your app handles

Votre application se charge de

  • RBAC / ABAC policy Politique RBAC / ABAC Which user can do what, under which conditions. Business-specific. Stays yours. Quel utilisateur peut faire quoi, sous quelles conditions. Spécifique au métier. Reste chez vous.
  • Business rules Règles métier Pricing tiers, feature flags, workflow gates — every rule that encodes your product strategy. Plans tarifaires, feature flags, contrôles de workflow — toute règle qui encode votre stratégie produit.
  • Tenant data Données tenant Records, files, transactions — never touched by authicto. The identity layer sees the user, not the payload. Enregistrements, fichiers, transactions — jamais touchés par authicto. La couche identity voit l'utilisateur, pas le contenu.
  • Domain workflows Workflows métier The flows that make your product valuable. Identity is an input — not a dependency on your team's focus. Les flux qui donnent sa valeur à votre produit. L'identité est une entrée — pas un appel sur le temps de votre équipe.
  • Integration surface Surface d'intégration One callback endpoint. One token introspection call per request. That's the contract. Un endpoint de callback. Un appel d'introspection par requête. C'est le contrat.
Authorization is business logic — yours. Identity is plumbing — ours. L'authorization, c'est la logique métier — elle est à vous. L'identité, c'est la plomberie — elle est à nous. Les mélanger, c'est ainsi que naissent les violations de données.

Onboard a new product in one config file. Embarquer un nouveau produit dans un seul fichier de config.

Every tenant gets its own client ID, its own redirect URIs, its own scopes, its own rate limits — declared once, served everywhere. Secrets live in Vault — never in a Git repository, never in an environment variable visible to the rest of the stack. Chaque tenant obtient son propre client ID, ses propres redirect URIs, ses propres scopes, ses propres rate limits — déclarés une fois, servis partout. Les secrets vivent dans Vault — jamais dans un dépôt Git, jamais dans une variable d'environnement visible par le reste du stack.

# authicto — tenant registry (excerpt)
clients:
  - client_id: medictom-rp
    name: Medictom
    grant_types: [authorization_code, refresh_token]
    redirect_uris:
      - https://app.medictom.ma/auth/callback
    scopes: [openid, profile, cnie, offline_access]
    token_endpoint_auth_method: client_secret_basic
    acr_values_supported:
      - urn:authicto:acr:1
      - urn:authicto:acr:2

  - client_id: fintech-alpha
    name: Fintech Alpha
    grant_types: [authorization_code, refresh_token]
    redirect_uris:
      - https://alpha.example.ma/auth/callback
    scopes: [openid, profile, cnie]
V
Per-tenant secrets in Vault Secrets par tenant dans Vault

Each client secret lives at secret/authicto/clients/<id>. Rotation does not require a restart.

Chaque client secret vit à secret/authicto/clients/<id>. La rotation ne nécessite pas de redémarrage.

R
Per-tenant rate limits Rate limits par tenant

Rate limits live at the edge, scoped to each client ID. One tenant's traffic storm never touches another.

Les rate limits sont appliqués en bordure, scopés par client ID. Un pic de trafic d'un tenant n'atteint jamais un autre.

B
Per-tenant branding Branding par tenant

The login page picks up the tenant's logo, colours, and legal footer from the registry. No code change, no deploy.

La page de login reprend le logo, les couleurs et la mention légale du tenant depuis le registry. Pas de changement de code, pas de déploiement.

C
Per-tenant consent registry Registre de consentement par tenant

Consent records are partitioned by client ID. Revocation in one tenant never affects sessions in another.

Les enregistrements de consentement sont partitionnés par client ID. Une révocation chez un tenant n'affecte jamais les sessions d'un autre.

Three HTTP calls. That's the integration. Trois appels HTTP. C'est ça, l'intégration.

authicto speaks standard OIDC. If your stack has an HTTP client — which it does — the integration fits on a postcard. No proprietary SDK, no lock-in, no surprise upgrades. The protocol is the SDK. authicto parle le standard OIDC. Si votre stack dispose d'un client HTTP — ce qui est le cas — l'intégration tient sur une carte postale. Pas de SDK propriétaire, pas de lock-in, pas de mises à jour surprises. Le protocole, c'est le SDK.

01

Discovery

Discovery

Read the OIDC discovery document. Every endpoint your client needs (authorize, token, JWKS, introspection, end_session) is advertised there.

Lire le discovery document OIDC. Chaque endpoint dont votre client a besoin (authorize, token, JWKS, introspection, end_session) y est annoncé.

$ curl https://auth.example.ma/.well-known/openid-configuration

{
  "issuer":                 "https://auth.example.ma",
  "authorization_endpoint": "https://auth.example.ma/auth",
  "token_endpoint":         "https://auth.example.ma/token",
  "jwks_uri":               "https://auth.example.ma/jwks",
  "introspection_endpoint": "https://auth.example.ma/token/introspection",
  "end_session_endpoint":   "https://auth.example.ma/session/end",
  "response_types_supported": ["code"],
  "id_token_signing_alg_values_supported": ["RS256"]
}
02

Token exchange

Échange de token

After the user returns to your callback with an authorization code, exchange it at the token endpoint. PKCE is mandatory — plain method is refused at the protocol level.

Lorsque l'utilisateur revient vers votre callback avec un authorization code, échangez-le au token endpoint. PKCE est obligatoire — la méthode plain est refusée au niveau du protocole.

$ curl -X POST https://auth.example.ma/token \
    -u "$CLIENT_ID:$CLIENT_SECRET" \
    -d grant_type=authorization_code \
    -d code="$AUTH_CODE" \
    -d code_verifier="$PKCE_VERIFIER" \
    -d redirect_uri="$REDIRECT_URI"

{
  "access_token":  "eyJhbGci…",
  "id_token":      "eyJhbGci…",
  "refresh_token": "gCrRjN…",
  "token_type":    "Bearer",
  "expires_in":    3600,
  "scope":         "openid profile cnie"
}
03

Introspection

Introspection

On each protected request, validate the access token via RFC 7662 introspection. The sub claim is an opaque DGSN-issued identifier. role and acr appear only if the scope permits.

À chaque requête protégée, validez l'access token via l'introspection RFC 7662. Le claim sub est un identifiant opaque émis par le DGSN. role et acr n'apparaissent que si le scope le permet.

$ curl -X POST https://auth.example.ma/token/introspection \
    -u "$CLIENT_ID:$CLIENT_SECRET" \
    -d token="$ACCESS_TOKEN"

{
  "active":      true,
  "sub":         "f7e2a1c9-…",   // opaque — DGSN-issued, not derivable
  "acr":         "urn:authicto:acr:2",
  "role":        "citizen",
  "client_id":   "medictom-rp",
  "scope":       "openid profile cnie",
  "token_type":  "Bearer",
  "exp":         1776724115
}

Fourteen guarantees. Proven in CI, not in a slide deck. Quatorze garanties. Prouvées en CI, pas dans une présentation.

Every guarantee below is an automated end-to-end test. Green bar in continuous integration, or authicto does not deploy. Each one traces back to a numbered section in the architecture document — so a reviewer can audit the claim, not just read it. Chaque garantie ci-dessous est un test automatisé de bout en bout. Barre verte en continuous integration, sinon authicto ne déploie pas. Chacune renvoie à une section numérotée du document d'architecture — le reviewer peut auditer la promesse, pas seulement la lire.

VERIFIED IN CI VÉRIFIÉ EN CI
14 / 14 GUARANTEES 14 / 14 GARANTIES
01§ 5.1

End-to-end OIDC flow

Flux OIDC de bout en bout

Authorization Code + PKCE S256, from initiation to active session, fully traceable and reproducible.

Authorization Code + PKCE S256, de l'initiation à la session active, entièrement traçable et reproductible.

Verified Vérifié
02§ 5.4

Ten-step token validation

Validation token en dix étapes

Signature, iss, aud, exp, iat, nbf, nonce, JTI, ACR, sub. Every step logs before it rejects.

Signature, iss, aud, exp, iat, nbf, nonce, JTI, ACR, sub. Chaque étape journalise avant de rejeter.

Verified Vérifié
03§ 5.3

JWKS lock under load

Lock JWKS sous charge

A distributed Redlock guards JWKS refresh against thundering-herd concurrent fetches — exactly one fetch in flight.

Un Redlock distribué protège le refresh JWKS contre la ruée concurrente — exactement un fetch en vol.

Verified Vérifié
04§ 5.2

Multi-tab concurrency

Concurrence multi-onglets

Strict per-tab OIDC state isolation in Redis — no overwrites, each state consumed exactly once.

Isolation stricte de l'état OIDC par onglet dans Redis — pas d'écrasement, chaque state consommé une seule fois.

Verified Vérifié
05§ 5.5

JTI replay detection

Détection de rejeu JTI

Every consumed token lands in a shared replay cache. A second presentation is rejected at the edge.

Chaque token consommé est enregistré dans un cache de rejeu partagé. Une seconde présentation est rejetée en bordure.

Verified Vérifié
06§ 6.3

Session version counter

Compteur de version de session

Atomic increment on the primary database. Older-version sessions become invalid instantly.

Incrément atomique sur la base primaire. Les sessions en version antérieure deviennent invalides instantanément.

Verified Vérifié
07§ 7.4

Identity revocation fan-out

Fan-out de révocation d'identité

An admin revoke invalidates every Redis session for that user via prefix scan — no window for a revoked token to be accepted.

Une révocation admin invalide chaque session Redis de cet utilisateur par scan de préfixe — pas de fenêtre pour qu'un token révoqué soit accepté.

Verified Vérifié
08§ 8.1

ACR step-up

Step-up ACR

A sensitive operation triggers second-factor re-authentication — controlled transition from standard to high assurance (ACR:1 → ACR:2 in OIDC terms). Never a silent upgrade.

Une opération sensible déclenche une re-authentification par second facteur — transition contrôlée d'une assurance standard vers une assurance élevée (ACR:1 → ACR:2 en termes OIDC). Jamais une élévation silencieuse.

Verified Vérifié
09§ 8.3

Step-up revocation guard

Garde de révocation au step-up

Revocation status is re-checked before any ACR update. A revoked user mid-flow cannot complete the upgrade.

Le statut de révocation est revérifié avant toute mise à jour ACR. Un utilisateur révoqué en cours de flux ne peut pas terminer l'élévation.

Verified Vérifié
10§ 7.2

Consent enforcement

Application du consentement

Every attribute access checks an active, versioned, timestamped consent. Revocation triggers automated removal.

Chaque accès à un attribut vérifie un consentement actif, versionné et horodaté. La révocation déclenche une exclusion automatique.

Verified Vérifié
11§ 4.6

Vault token auto-renewal

Renouvellement automatique du token Vault

Watchdog thread re-authenticates to Vault before token expiry — zero downtime on the identity layer. Client secret hot-reload ships in the next phase.

Le thread watchdog se ré-authentifie auprès de Vault avant l'expiration du token — zéro downtime sur la couche identity. Le hot-reload des secrets clients arrive dans la prochaine phase.

Verified Vérifié
12§ 5.7

Discovery cache fallback

Fallback de cache discovery

Three-tier cache — Redis → live → filesystem. An IdP discovery outage does not degrade authentication.

Cache à trois niveaux — Redis → live → filesystem. Une indisponibilité du discovery IdP ne dégrade pas l'authentification.

Verified Vérifié
13§ 9.2

Clock drift monitoring

Supervision de dérive d'horloge

Clock offset > 2 s triggers a Prometheus alert and rejects tokens outside the configured tolerance.

Un décalage d'horloge > 2 s déclenche une alerte Prometheus et rejette les tokens en dehors de la tolérance configurée.

Verified Vérifié
14§ 7.1

Append-only audit log

Journal d'audit append-only

A PostgreSQL trigger blocks UPDATE and DELETE at the engine level. Every event is mirrored to SIEM, non-repudiable by construction.

Un trigger PostgreSQL bloque UPDATE et DELETE au niveau moteur. Chaque événement est miroité vers SIEM, non-répudiable par construction.

Verified Vérifié

Five laws. One architecture that answers to each. Cinq textes. Une architecture qui répond à chacun.

The non-negotiable constraints — data sovereignty, minimal disclosure, non-repudiable logs — are encoded in the code, not in a policy document that nobody reads. Every obligation below is a test; every test is a gate on the release pipeline. Les contraintes non-négociables — souveraineté des données, divulgation minimale, logs non-répudiables — sont encodées dans le code, pas dans un document de politique que personne ne lit. Chaque obligation ci-dessous est un test ; chaque test est un verrou sur la pipeline de release.

04–20

Loi 04–20 · Carte Nationale d'Identité Électronique

Loi 04–20 · Carte Nationale d'Identité Électronique

Legal framework for the CNIE, its chip-backed identity assertions, and their use by relying services. DGSN is the authoritative identity gateway — authicto accepts exactly the claims the law authorises, nothing more.

Cadre juridique de la CNIE, de ses assertions d'identité adossées à la puce et de leur exploitation par les services relyants. Le DGSN est la passerelle d'identité faisant autorité — authicto accepte exactement les claims autorisés par la loi, rien de plus.

Art. 4 · 11 · 16
09–08

Loi 09–08 · Personal data protection

Loi 09–08 · Protection des données à caractère personnel

Minimisation, explicit versioned consent, right of access and rectification. CIN is hashed with HMAC-SHA256 — key held in Vault, never stored in clear text.

Minimisation, consentement explicite versionné, droit d'accès et de rectification. CIN haché en HMAC-SHA256 — clé dans Vault, jamais stocké en clair.

Art. 2 · 4 · 7 · 14
43–20

Loi 43–20 · Electronic trust services

Loi 43–20 · Services de confiance électroniques

Qualified electronic signature, timestamping, identification. Interoperable with the national trust gateway.

Signature électronique qualifiée, horodatage, identification. Interopérable avec la passerelle nationale de confiance.

Art. 3 · 8 · 22
05–20

Loi 05–20 · Cybersecurity

Loi 05–20 · Cybersécurité

Obligations for operators of vital importance — incident management, notification, continuity of authentication services. authicto's runbook is shipped alongside the code.

Obligations des opérateurs d'importance vitale — gestion d'incidents, notification, continuité des services d'authentification. Le runbook d'authicto est livré à côté du code.

Art. 5 · 11 · 18
2023

DNSSI 2023 · National InfoSec directive

DNSSI 2023 · Directive Nationale de Sécurité des Systèmes d'Information

National reference — data classification, encryption requirements at rest and in transit, full auditability of access. authicto maps each rule to a verifiable control in the stack.

Référentiel national — classification, exigences de chiffrement au repos et en transit, auditabilité complète des accès. authicto fait correspondre chaque règle à un contrôle vérifiable du stack.

CH. 2 · § 4

All controls are code-enforced and verified by automated tests. External validation — CNDP declaration (Loi 09-08 Art. 12) and DGSSI-qualified penetration test (Loi 05-20) — is in progress as required by law before the first production tenant goes live. Tous les contrôles sont appliqués par le code et vérifiés par des tests automatisés. La validation externe — déclaration CNDP (Loi 09-08 Art. 12) et test de pénétration qualifié DGSSI (Loi 05-20) — est en cours conformément à la loi, avant la mise en production du premier tenant.

Pluggable identity proofing. Ready for DGSN / ADD. Identity proofing pluggable. Prêt pour DGSN / ADD.

authicto's identity proofing backend is pluggable by design. The sandbox build runs password + TOTP MFA end-to-end today. When the DGSN/ADD SDK ships, it replaces the sandbox backend via a single configuration change — no code change on the tenant side, no changes to the OIDC interface. The integration is done; the SDK is not. Le backend de proofing d'authicto est pluggable par conception. Le build sandbox couvre password + TOTP MFA de bout en bout aujourd'hui. Quand le SDK DGSN/ADD sera disponible, il remplace le backend sandbox par un changement de configuration — aucune modification côté tenant, aucun changement d'interface OIDC. L'intégration est prête ; c'est le SDK qui ne l'est pas encore.

From sandbox to production-grade. Du sandbox à la production gouvernementale.

The 14 DGSN sandbox scenarios are complete and verified. The build-out to full production readiness follows a structured plan — each phase ships tested and documented before the next begins. Les 14 scénarios sandbox DGSN sont complets et vérifiés. Le déploiement vers une production complète suit un plan structuré — chaque phase est livrée testée et documentée avant que la suivante ne commence.

Phase 1 — In development
Phase 1 — En développement

Operational hardening

Durcissement opérationnel

  • PostgreSQL health check (fail-fast on DB outage)
  • Health check PostgreSQL (fail-fast sur panne DB)
  • Session ID rotation on step-up (session fixation prevention)
  • Rotation du session ID au step-up (prévention de fixation)
  • Circuit breakers for Vault, JWKS, DGSN token endpoint
  • Circuit breakers pour Vault, JWKS, endpoint token DGSN
  • Per-IP rate limit on /auth/callback
  • Rate limit par IP sur /auth/callback
In progress En cours
Phase 2 — Admin console
Phase 2 — Console admin

Tenant lifecycle management

Gestion du cycle de vie des tenants

  • Admin console UI — tenant list, create, detail
  • Interface admin — liste, création, détail des tenants
  • Client secrets managed in Vault — shown once, rotatable
  • Secrets clients dans Vault — affichés une fois, rotables
  • CNDP declaration + PDF upload gating tenant activation
  • Déclaration CNDP + PDF bloquant l'activation du tenant
  • Logo URL proxying — no external Referer leakage
  • Proxy logo URL — pas de fuite Referer externe
Planned Planifié
Phase 3 — Compliance
Phase 3 — Conformité

Named operators & audit lifecycle

Opérateurs nommés & cycle de vie de l'audit

  • Named operator tokens — per-operator Vault-issued credentials
  • Tokens opérateurs nommés — credentials Vault par opérateur
  • Audit anonymisation — sub NULLed after 1-year retention
  • Anonymisation de l'audit — sub NULLé après 1 an de rétention
  • Audit log partitioning + cold storage archival
  • Partitionnement du journal d'audit + archivage froid
Planned Planifié
Phase 4 — Integrations
Phase 4 — Intégrations

Webhooks & mTLS

Webhooks & mTLS

  • Outbound webhooks — HMAC-SHA256, retry with backoff
  • Webhooks sortants — HMAC-SHA256, retry avec backoff
  • mTLS RP → DGSN — CA bundle in Vault, watchdog-refreshed
  • mTLS RP → DGSN — bundle CA dans Vault, rafraîchi par watchdog
  • Client secret hot-reload — poll Vault every 60s, no restart
  • Hot-reload des secrets — poll Vault toutes les 60s, sans redémarrage
Planned Planifié
Phase 5–6 — User features
Phase 5–6 — Fonctionnalités utilisateurs

WebAuthn, RTL & observability

WebAuthn, RTL & observabilité

  • FIDO2/WebAuthn as ACR:3 factor
  • FIDO2/WebAuthn comme facteur ACR:3
  • Arabic / RTL support on tenant interaction pages
  • Support arabe / RTL sur les pages d'interaction tenant
  • OpenTelemetry tracing → Grafana Tempo
  • Traçage OpenTelemetry → Grafana Tempo
  • Synthetic monitoring — fresh-citizen end-to-end every 5 min
  • Monitoring synthétique — parcours citoyen complet toutes les 5 min
Later Ultérieur
Phase 7 — Enterprise hardening
Phase 7 — Durcissement entreprise

HA infrastructure & SCIM

Infrastructure HA & SCIM

  • SCIM 2.0 — /Users, /Groups provisioning
  • SCIM 2.0 — provisionnement /Users, /Groups
  • Vault 3-node Raft cluster + HSM auto-unseal
  • Vault cluster Raft 3 nœuds + HSM auto-unseal
  • PostgreSQL streaming replica + WAL archiving (RPO < 1h)
  • Réplica streaming PostgreSQL + archivage WAL (RPO < 1h)
  • Redis Cluster 3+3 — replaces Sentinel
  • Redis Cluster 3+3 — remplace Sentinel
Later Ultérieur
External gates — run in parallel
Jalons externes — en parallèle

Regulatory & SDK

Réglementaire & SDK

  • CNDP declaration filed — authentication-only processing
  • Déclaration CNDP déposée — traitement authentification uniquement
  • DGSSI-qualified penetration test (Loi 05-20)
  • Test de pénétration qualifié DGSSI (Loi 05-20)
  • DGSN/ADD SDK integration — CNIE chip proofing live mode
  • Intégration SDK DGSN/ADD — mode live du proofing puce CNIE
External dependency Dépendance externe
Architecture-driven delivery. Every phase is backed by formal architecture documentation (22 sections), automated tests, and a compliance mapping to Moroccan law. Nothing ships unless the test suite passes. Livraison pilotée par l'architecture. Chaque phase est adossée à une documentation d'architecture formelle (22 sections), des tests automatisés et un mapping de conformité au droit marocain. Rien n'est livré si la suite de tests n'est pas au vert.

Data submitted via this form is processed in accordance with Loi 09–08 on personal data protection. Hosting on Moroccan territory. Les données transmises via ce formulaire sont traitées conformément à la Loi 09–08 relative à la protection des données à caractère personnel. Hébergement sur territoire marocain.