Request an organisation
Share the organisation details and domains you represent. A platform administrator reviews the request before access is set up.
One identity for institutions. Access with accountability.
Manage institution membership and connect approved services through one account. Each service keeps control of its own users, roles and permissions.
Building a service? Read the integration guideOrganisation requests are reviewed before access is granted.
Taifa components
Purpose-built UI,
within clear boundaries
Interface patterns for sign-in, account management, Institution membership and approved application access. Each is shaped around the Taifa identity model.
Explore the integration guide
Sign in to Taifa
Use your enrolled authenticator to continue.
or
Institution email
Enter your institution email
Accounts are provisioned by invitation.
Taifa One · Interface illustration
Illustrative names and portraits. No account changes.
Sign in with an enrolled authenticator, review account details and manage protected sessions.
Authentication and lifecycle
Everything for accountable access.
Strong sign-in is one part of the decision. Sponsorship, product roles, and session changes each keep a clear authority.
Explore the security modelMultifactor authentication
Verify with an enrolled passkey or password with TOTP. Privileged access follows a stronger policy.
Institutional SSO
Reviewed provider configuration must prove equivalent assurance. Account linking preserves the permanent issuer and subject.
Passkeys and strong sign-in
Use an enrolled passkey or password with TOTP. Sensitive changes require a fresh strong sign-in.
DeviceCurrent browser
AuthorityCentral sign-in
ApplicationLocal session
Session management
Applications must act on central logout and session changes, while protecting their own sessions.
Product owned permissions
A permanent person key identifies you. Each product decides its own local accounts, roles and permissions.
Safeguarded sign-in
Sign-in policies protect access. Sensitive actions require strong authentication and scoped authority.
Enrolled one-time codes
Enrolled authenticators supply TOTP as a second factor. Policy determines the required assurance.
Invitation links
Scoped invitations and approved provisioning start enrollment. A link never grants product roles.
Protected passwords
Passwords and enrolled TOTP stay within Taifa One. Recovery requires independent approval.
Reviewed application clients
Named owners. Exact redirects. Independent approval.
Auditable changes
Scoped authority. Fresh strong sign-in. A reason and a durable audit record.
Illustrative security visuals. No account or credential data is shown.
Institution governance
Everything your Institution needs.
Institutions sponsor membership and review eligibility. Each product keeps its local accounts, roles and permissions.
Sponsored membership
A named sponsor confirms membership. Review establishes eligibility before workforce access.
Jotham Mwangi · illustrative member
Jotham Mwangi · illustrative workforce membershipReview before access
Scoped authority and a recorded reason establish accountable membership.
Invitation-led enrollment
Invitations and approved provisioning establish accounts. There is no public self-registration.
jotham.mwangi@moh.test
Illustrative invitationInstitution and project workspaces
Reviewed membership and named project ownership keep every access boundary explicit.
MOH workspace
Sponsored membership
Reviewed eligibility
Scoped lifecycle
Product roles stay with the product.
Interactive illustration, no access changes.
Application authority
One identity.
Your application’s rules.
Taifa provides a permanent person key and reviewed eligibility. Your application owns its local accounts and roles.
- Map people by issuer and subject
- Keep permission decisions in your application
IllustrationAccess that belongs to your app.
A reviewed person. A role you control.
Taifa One
Person and eligibilityJotham MwangiMOH workforce example
- Issuer
- identity.govconnect.ke
- Subject
- 8f2a…c94e
Membership reviewed
Project eligibility reviewed
Identity does not assign your role
Health Records
Local account and rolesLocal account
jmwangi_047Mapped to the same issuer + subjectCan view project records
Permissions stay in your application
Illustrative name and portrait. No account changes.
Frameworks
Build with standard OIDC libraries
Use a maintained OIDC library for authorization code, PKCE, discovery and token validation on web or native clients.
Integration quickstartIntegrations
Connect the applications you operate
The planned rollout connects Taifa products while each retains its own accounts, roles and operational data.
Connect a website
Start with approval.
Use your existing Taifa account to request an organization for independent review, or prepare a website for integration.
Taifa One is currently in preview.Can I create my own account?
There is no public self-registration. Ask your Institution sponsor about an invitation or approved provisioning.
Who decides product permissions?
Applications retain local accounts, roles and the final authorization decision. Sign-in alone does not grant a role.
How do I connect an application?
Obtain an approved staging client, then follow the integration quickstart and lifecycle contract.
Is Identity in production?
Taifa One is in preview. Reviewed integration, security and operational release gates remain required.
One permanent person key
Identity uses the issuer and subject. An email address is contact information, never the account merge key.
Identity modelTaifa One documentationStrong authentication
Managed staff require a user-verifying passkey or password plus TOTP. Privileged access follows a stronger policy.
MFA and recoveryTaifa One documentationReviewed project registration
Named owners, exact HTTPS callbacks and independent approval establish the client boundary before integration.
Project approvalTaifa One documentationStandards-based integration
Use maintained OIDC libraries for authorization code, PKCE, discovery and token validation. Begin with a reviewed staging client.
Integration quickstartTaifa One documentationInvitation-led enrollment
A named Institution sponsor and an authorized review establish membership before workforce access.
Membership and sponsorshipTaifa One documentationProduct-owned permissions
Each application keeps local accounts and roles. A successful central sign-in does not automatically grant product access.
Application integrationTaifa One documentationScoped lifecycle delivery
Applications apply approved changes and track their last applied cursor. Protected access is denied when freshness expires.
Lifecycle contractTaifa One documentationExplicit preview status
Production approval depends on completed integration, security and operational release gates. A guide is not proof of deployment.
AvailabilityTaifa One documentation