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 fournisseur d'identité OIDC pensé pour les applications marocaines.

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é ne se résout jamais à moitié. authicto en décharge entièrement votre équipe produit : hébergement souverain, trois appels HTTP standard, une conformité certifiée aux textes marocains réellement appliqués.

ProtocolProtocole OIDC Authorization Code

Proof 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

§ For whom § Pour qui

Built for teams who ship to real users. Pensé pour les équipes qui construisent pour 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, une déclaration fiscale, ou toute donnée sensible — l'identité est la première ligne de défense. authicto est cette ligne.

Healthtech Healthtech

Patient portals. Practitioner consoles.

Portails patients. Espaces 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 engage une responsabilité juridique que la plupart des équipes produit n'ont pas les moyens d'assumer. authicto s'en charge.

→ 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ù l'assurance d'identité est 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.

Des services citoyens qui ne tolèrent aucune connexion frauduleuse. Avant une opération sensible, authicto peut exiger un second facteur — un code à usage unique généré par une application d'authentification — sans reconnexion complète.

→ 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.

Les applications B2B dont le premier grand compte exige du SSO — et n'accepte pas de réponse du type « c'est prévu sur la roadmap ». authicto, c'est la réponse livrable dès 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.

§ Separation of concerns § Séparation des responsabilités

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

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 à comprendre, à auditer et à faire évoluer.

Identity layer Couche identité

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 modulaire — le SDK DGSN/ADD s'intègre dès sa sortie.
Authentication & step-up Authentification & 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 — sans reconnexion complète.
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 de la base de données, miroité vers le SIEM, non-répudiable par construction.

Authorization layer Couche autorisation

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 traduit votre stratégie produit.
Tenant data Données du 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 identité 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 toute sa valeur à votre produit. L'identité n'est qu'une entrée — elle ne mobilise pas l'attention 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'autorisation, 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.

§ Multi-tenant by design § Multi-tenant par conception

Onboard a new product in one config file. Intégrer un nouveau produit en un seul fichier de configuration.

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]

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.

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, cantonnés à chaque client ID. Un pic de trafic d'un tenant n'atteint jamais un autre.

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 registre. Pas de changement de code, pas de déploiement.

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.

§ Integration § Intégration

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.

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"]
}

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"
}

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
}

§ Proven guarantees § Garanties prouvées

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 CI, sinon authicto ne déploie pas. Chacune renvoie à une section numérotée du document d'architecture — le reviewer peut auditer la preuve, 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 du 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

Verrouillage 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 rafraîchissement du JWKS contre la ruée concurrente — un seul fetch en vol à la fois.

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 toutes les sessions Redis de l'utilisateur par balayage de préfixe — aucune fenêtre ne permet 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 ré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

Vérification 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 identité. Le hot-reload des secrets clients arrive dans la prochaine phase.

Verified Vérifié

12§ 5.7

Discovery cache fallback

Repli du cache de 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 le SIEM, non-répudiable par construction.

Verified Vérifié

§ Legal compliance § Conformité légale

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 built into the code, not written into 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, journaux non-répudiables — sont directement intégrées au code, pas dans un document de politique que personne ne lit. Chaque obligation ci-dessous est un test ; chaque test verrouille le pipeline de déploiement.

04–20

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 usage par les services qui s'y appuient. Le DGSN est la passerelle d'identité faisant autorité — authicto n'accepte que les claims que la loi autorise, 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 et versionné, droit d'accès et de rectification. Le CIN est haché avec HMAC-SHA256 — la clé reste dans Vault, jamais stockée 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é avec le code source, pas séparément.

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.

§ Partners & SDK integration § Partenaires & intégration SDK

Pluggable identity proofing. Ready for DGSN / ADD. Identity proofing modulaire. 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 modulaire par conception. Le build sandbox couvre password + TOTP MFA de bout en bout aujourd'hui. Quand le SDK DGSN/ADD sera disponible, il remplacera le backend sandbox par un simple 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.

§ What's next § Ce qui arrive

From sandbox to production-grade. Du sandbox à la production réelle.

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 de l'URL du logo — 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 d'opérateurs nommés — identifiants 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

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 du 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
Cluster Vault Raft à 3 nœuds + HSM auto-unseal
PostgreSQL streaming replica + WAL archiving (RPO < 1h)
Réplica PostgreSQL en streaming + 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 pour le proofing par 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 une cartographie de conformité au droit marocain. Rien n'est livré si la suite de tests n'est pas au vert.

§ Get in touch § Prendre contact

Talk to the team. Parler à l'équipe.

Tenant evaluation, technical integration, partnership — or just an exploratory chat. Morocco-based support, straight answers, no sales fluff. Évaluation tenant, intégration technique, partenariat — ou simplement un premier échange exploratoire. Support basé au Maroc, réponses franches, sans blabla commercial.

Territory Territoire Kingdom of Morocco Royaume du Maroc

Hosting Hébergement Sovereign · national territory Souveraineté · territoire national

Protocol Protocole OIDC Authorization Code + PKCE S256

Architecture reference Référence d'architecture v1.0 — FINAL

Technical documentation Documentation technique Full architecture reference — 22 sections, 40 verified test scenarios — available on request. Référence d'architecture complète — 22 sections, 40 scénarios de test vérifiés — disponible sur demande.

First name * Prénom *

Last name * Nom *

Organisation * Organisation *

Email address * Adresse e-mail *

Subject * Objet *

Message * Message *

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.