FASTCLINIC SOLUTION · FASTLOGIN

One sign-in for every Fastclinic product.

Verified identity, phishing-resistant MFA, and OAuth2 / OIDC for the whole ecosystem. Sign in once. Use Doorcta, OneHealth, FastCredits, and every partner app — without ever rebuilding auth.

Request demoRead the docs
fastlogin.fastclinic.xyz/login
Sign in to Fastclinic
Sign in with passkey
Use password instead
Continue · 15-min access · 24-hr refresh
Choose your path
I'm a

Patient

Sign in once, use every Fastclinic product.

Read this view →
I'm a

Healthcare Provider

Verified clinical access, KYC, MFA — once.

Read this view →
I'm a

Organisation Admin

Provision a hospital. Assign entitlements. Audit it.

Read this view →
FastLogin is the identity layer of the Fastclinic ecosystem — one verified account, one MFA enrolment, one consent record, every product.

Healthcare apps in Nigeria still ship their own login screens, their own KYC checks, their own audit logs. Every duplication is a place users get fatigued, providers get unverified, and regulators get a different story from each system. FastLogin replaces all of it with a single, NDPA 2023-compliant identity service. Patients verify their phone and email once. Providers upload their MDCN licence once and pass a Didit liveness check once. Organisations provision their staff once. From there, every Fastclinic product — and every partner app that integrates the SSO — speaks to the same identity, the same hash-chained audit log, the same scope-limited OAuth2 token. The credentials never leave Lagos. The audit trail is hash-chained and exported daily to write-once storage. The token any product holds expires every fifteen minutes. We treat identity the way the rest of the platform treats records: encrypted, scoped, expiring, and provably tamper-evident. The architecture is opinionated. It picks Ory Kratos for credential storage and Ory Hydra for OAuth2 because reimplementing either is a mistake every healthcare startup eventually regrets. It picks passkeys plus TOTP plus backup codes because no single factor is enough at NIST AAL2. It picks African data residency because residency is not a switch you flip later. It picks a hash-chained audit because regulators ask for evidence, not assurances. The full Hydra issuer is locked at fastlogin.fastclinic.xyz. Every relying party — Fastclinic-built or partner — points at that single issuer string and trusts no one else. When a key rotates in Hydra, every relying party picks up the new key within five minutes through the standard JWKS poll. When a session is revoked in Kratos, every product sees the revocation by the time the access token next refreshes. Identity is a system, not a feature. Building it once and reusing it everywhere is the difference between an ecosystem of products and four loosely related apps.

Capabilities

Auth
  • Email + phone verification (OTP)
  • Passkey (WebAuthn / FIDO2)
  • TOTP authenticator app
  • Backup recovery codes (lookup_secret)
  • Password as fallback only
  • Session-bound CSRF on every flow
MFA / step-up
  • Phishing-resistant by default
  • AAL2 step-up before sensitive scopes
  • Per-device session listing + revoke
  • Configurable step-up freshness window
  • Hardware-key support (YubiKey / Titan)
KYC
  • Didit liveness (passive single-frame)
  • iBeta Level 1 PAD certified
  • MDCN licence verification (provider)
  • NIN verification (patient)
  • 3 retry attempts before terminal decline
  • 30-day Didit retention, 24-hour purge
OAuth2 / OIDC
  • 15-min access tokens
  • 24-hour refresh with rotation
  • JWKS · 5-min cache
  • Scope-limited consent screen
  • Authorization-code with PKCE
  • Client-credentials for service tokens
Audit
  • Hash-chained event log
  • 7-year retention
  • Daily export to WORM S3
  • Africa/Lagos timezone
  • After-hours flagging (08:00–18:00)
  • Per-IP and per-device columns
Compliance
  • NDPA 2023 §25 lawful basis
  • African data residency
  • Documented data-processing record
  • DSAR export pipeline
  • Cross-product consent ledger
  • Quarterly third-party pentest

Under the hood

What ships when you ship this. The architecture is built once and inherited by every Fastclinic product.

SIGN IN · REGISTER · MFAOAUTH2 CONSENTEVERY EVENTPUBLISH KEYSACCESS · 15-MINACCESS · 15-MINACCESS · 15-MINVERIFYVERIFYVERIFYPATIENT · PROVIDER · ADMINORY KRATOS · IDENTITYORY HYDRA · OAUTH2 / OIDCJWKS · 5-MIN CACHEAUDIT LOG · HASH-CHAINEDDOORCTAONEHEALTHFASTCREDITS
15-min access tokens · 24-hr refresh
Hydra issues short-lived access tokens; refresh tokens rotate on every use. Compromise window measured in minutes, not weeks.
JWKS · 5-min cache
Each product caches FastLogin's public keys for 5 minutes. Key rotation propagates without redeploy.
AAL2 step-up · phishing-resistant
Sensitive operations require AAL2 — passkey or TOTP, not just a password. Kratos enforces; Hydra checks before issuing scoped tokens.

Integrations

Fastclinic
Doorcta

Telehealth signs patients and doctors in via FastLogin. Consult start requires AAL2 within the last fifteen minutes. Doorcta never sees the user's password.

Fastclinic
OneHealth

Health-record access requires AAL2 plus an explicit scope on the consent screen. Provider identity is the MDCN-verified FastLogin identity — there is no separate clinical login.

Fastclinic
FastCredits

The shared credits ledger trusts FastLogin's identity for both individual and organisation accounts. Hold, capture, and refund actions all carry the FastLogin user ID and write to the same audit chain.

External
Ory Kratos

Open-source identity store. We run pinned releases and edit configuration at fastlogin/ory/kratos/. Container restarts are part of every config change.

External
Ory Hydra

Open-source OAuth2 / OIDC server. Tokens are signed with rotating keys; the public key set is cached by every relying party for five minutes. Hydra never sees user passwords.

External
Didit

External KYC processor for liveness, MDCN licence OCR, and NIN verification. Signed agreement under NDPA 2023; selfie data deleted after thirty days on Didit's side.

Compliance & safety

NDPA 2023 — lawful basis recorded

FastLogin processes personal data under contract, consent, legal obligation, and legitimate-interest bases per NDPA 2023 §25. Every dataset and processor is recorded in the data-processing record kept by the Fastclinic Limited data controller (RC 1919428).

NDPA 2023 (NDPC)
Audit log — 7-year hash chain, daily WORM export

Every authentication event is hashed into a Postgres-side chain. Tampering with any historical row breaks the chain. We export the chain daily to write-once-read-many S3 storage; the seven-year retention satisfies records-of-processing requirements.

African data residency

Identities, sessions, KYC artefacts, and audit logs are hosted in a Nigerian-region AWS account. Cross-border transfer is limited to the named Didit liveness flow under signed processor agreement.

Phishing-resistant MFA policy

Every FastLogin account holds both a passkey credential and a TOTP secret. Passkeys carry the phishing-resistance properties NIST 800-63 names as AAL2-eligible without an authenticator-app fallback. We require both factors so a lost device is recoverable.

NIST 800-63B
Token lifetimes — short by design

Access tokens last fifteen minutes. Refresh tokens last twenty-four hours and rotate on every use. JWKS caches expire every five minutes. Compromise windows are measured in minutes, not weeks.

Plain answers

01What does FastLogin actually do?
FastLogin is the identity layer that every Fastclinic product depends on. It handles registration, phone and email verification, KYC for providers, multi-factor authentication, OAuth2 / OIDC token issuance, session management, and the per-user audit trail. When a patient signs in to Doorcta to start a consultation, when a doctor signs in to OneHealth to access records, when a finance lead signs in to FastCredits to top up an org balance — they are all signing in through FastLogin. There is exactly one set of credentials per person across the entire ecosystem.
02Why centralise identity instead of letting each product do its own auth?
Because every duplicated auth surface is a duplicated attack surface, a duplicated KYC liability, and a duplicated source of audit drift. When a provider's MDCN licence is revoked, we want it revoked everywhere within minutes — not weeks. When a patient grants access to one product, we want that consent recorded against one ledger, not scattered across five databases. Centralising identity lets us run one well-monitored credential store, one phishing-resistant MFA policy, and one hash-chained audit log that regulators can verify.
03Is FastLogin a custom build or off-the-shelf?
It is a Go service built on Ory Kratos and Ory Hydra — both production-grade open-source identity stacks — with a Fastclinic-built admin and self-service UI on top. Kratos handles credential storage, MFA factors, recovery, and the registration state machine. Hydra handles OAuth2 / OIDC, scope enforcement, and token lifecycle. The Go service in front orchestrates KYC via Didit, the seven-year hash-chained audit trail, organisation entitlements, and the partner-client onboarding flow. We did not write a credential store ourselves and we are not going to.
04Where does the data live?
On African data residency: a Nigerian-region AWS account that the Fastclinic Limited (RC 1919428) data controller operates. Identities, sessions, MFA secrets, KYC artefacts, and audit logs do not leave that region in normal operation. The Didit liveness check is the one external processor: a selfie image is sent to Didit for the verification window, then deleted on Didit's side after thirty days and on our side within twenty-four hours of the verification result.
05How long do FastLogin tokens last?
Access tokens are valid for fifteen minutes. Refresh tokens are valid for twenty-four hours and rotate on every use, so a leaked refresh token is single-use. Each Fastclinic product caches FastLogin's public JWKS keys for five minutes, which means a key rotation propagates across the entire ecosystem in five minutes without any product redeploy. These numbers come from the runtime Hydra client config — they are not aspirational.
06What does AAL2 mean and why does FastLogin require it?
AAL2 is NIST's term for authentication assurance level 2 — the user has proven possession of a phishing-resistant factor like a passkey or a TOTP authenticator, not just a password. FastLogin enrols every user with both a passkey and a TOTP secret during registration so that no user is locked out if a single device is lost. Sensitive operations like clinical record access and financial actions require an AAL2-fresh session. Hydra refuses to issue scoped tokens for those scopes when the session is only AAL1.
07Can a third-party Nigerian healthcare app integrate FastLogin?
Yes — that is what the partner-client surface is for. We register your app as a Hydra OAuth2 client, point it at the standard authorization-code-with-PKCE flow, and your users get the same one-click sign-in and centralised consent screen that Doorcta and OneHealth use. Your app stores no passwords. Your app sees no MFA secrets. You get a verified user identity, the scopes the user consented to, and a fifteen-minute access token. Talk to the developer documentation for the integration timeline.
08What happens if FastLogin is down?
Existing fifteen-minute access tokens continue to validate against the cached JWKS until they expire. New sign-ins are blocked. The runbook recovery path is to roll back the most recent FastLogin or Kratos or Hydra deployment from the audit-immutable change log, page the on-call, and post a customer-facing status update within fifteen minutes of detection. Outage history and SLA targets live on the trust page. Critically, the cached-JWKS design means that for the first five minutes of any FastLogin issue, every relying party still validates already-issued tokens locally. That gives operators a real recovery window before user-visible impact, which is the difference between an SSO outage that takes the whole ecosystem down and one that the average user never notices.
09How do I integrate FastLogin into a third-party Nigerian app?
We register your app as a Hydra OAuth2 client with the redirect URIs and post-logout URIs you specify. You implement the standard authorization-code-with-PKCE flow against our well-known OIDC discovery document. On the success callback you receive an ID token (JWT) signed by Hydra; you verify it against our JWKS endpoint and read the user identity claims. Token refresh, user-info endpoint, and revocation all follow OAuth2 / OIDC standards verbatim — there is nothing Fastclinic-specific in the protocol layer. The Fastclinic-specific work is on your end: deciding which scopes you need, building your consent rationale text, and storing the user identity by FastLogin user ID rather than by email. The developer documentation walks through each step with code samples in TypeScript, Go, and Python.
10How is consent tracked across products?
Every consent grant is an event in the audit chain with the user ID, the requesting client (product or partner), the scope set, the timestamp, and the AAL of the session that granted it. When the user revokes consent for a scope, that is also an event — the chain shows the grant, the revoke, and the duration. Hydra enforces revocation by refusing to issue tokens for revoked scopes; existing access tokens with those scopes age out within fifteen minutes. The OneHealth team built their entire access-grant surface on this primitive, which is the kind of leverage you only get from one identity layer.

Ready to ship with FastLogin?

Request a 30-minute architecture review. We will walk through the integration points, the compliance posture, and the timeline.

Request demoRead the docs