Apache Fineract SSO and identity integration guide

How to add SSO to Apache Fineract without locking out staff or API clients

Adding single sign-on to Apache Fineract is the work of wiring Fineract's OAuth2 resource handling to an external identity provider, then mapping staff roles, maker-checker approvals and API client credentials onto identities that provider issues. The first decision is not the protocol. It is the inventory of every caller that authenticates to the platform today, because each one needs a defined path after the change. Most banks and lenders find that the staff web application is only one of several callers. Batch jobs, reconciliation scripts, reporting tools and partner integrations often authenticate with shared or basic credentials that nobody has written down. Those callers will break first if the identity cutover treats them as an afterthought. Fineract is headless. It exposes REST APIs and does not ship its own user interface, so the front end the staff use is one client among several. The README's Kubernetes example points to the Mifos X web application as a front end, but your deployment may use a different one. Integration clients, batch processes and any service that calls the API with a token all authenticate in the same way. The README also documents OAuth2 and HTTP basic authentication with a default development login. That default login must be removed for any real deployment, and you should confirm that no environment, container image or test fixture still accepts it before you announce the new identity source. Every request also carries the Fineract-Platform-TenantId header, so the identity check and the tenant context must be designed together. A token that is valid for one institution should not be accepted as valid for another. Roles are the second design point. Fineract's permissions are assigned through its own role and permission model, and the identity provider will supply groups or claims. Write a mapping table that links each external group to a Fineract role, and mark which roles can initiate a transaction and which can approve it. Maker-checker controls depend on the approver being a different identity from the maker, so confirm that the mapping keeps those two roles separate for every product and entity that requires dual approval. Test this with real accounts in a non-production instance rather than assuming the mapping works because the group names look right. Offboarding and API clients need their own rules. When a staff member leaves, disabling the identity provider account must also end access to Fineract, including any token that is still valid. Client credentials used by integrations should have named owners, rotation dates and a documented revocation step. The Fineract documentation strongly encourages HTTPS only, and SSL settings are configured through environment variables such as FINERACT_SERVER_SSL_ENABLED, so confirm TLS is enforced on every path between the identity provider, the front end and the API. The Fineract README warns that production deployments are complex and that the project does not provide a comprehensive production deployment guide. Nobody else will write the identity design for you. Before configuration starts, document the caller inventory, the token lifetimes, the role-to-group mapping, the approval rules, the offboarding procedure and the rollback plan, and have the security team sign off on that document. The written design is what lets the change go live without locking out staff or the systems that depend on them.

Which Fineract components and identity pieces are involved

Fineract authentication touches more than one login screen. The REST API, the front end, the identity provider, Fineract's own staff model and the tenant context all have to agree on who is calling, on whose behalf, and with which permissions. The cards below map each piece and list what to confirm against the documentation for the version you run.

Fineract REST API authentication

Fineract is headless and exposes its functions only through REST APIs, so the API is where authentication is enforced. The README shows OAuth2 and HTTP basic authentication as options. Confirm which mechanisms your release enables, how tokens are issued and validated, and which endpoints, if any, remain reachable without credentials.

Default development login

The README documents a default development login that must be changed for any real deployment. Treat it as a known credential that exists until removed. Confirm where it is defined in your release, how it is disabled or overwritten, and whether any automation, health check or seed script still depends on it before cutover.

Front end as an OAuth2 client

Mifos X is the front end used in the README's Kubernetes example, and it acts as an OAuth2 client rather than a source of identity. Your team must decide how it obtains tokens, how sessions expire, and how logout reaches the identity provider. Confirm the client registration steps and redirect configuration for the front end version you deploy.

External identity provider

The identity provider holds the people and groups that sign in, and it is the system your security team will audit first. Decide which claims or groups it issues, how they map to Fineract users, and how deprovisioning a leaver removes access in Fineract. Confirm token lifetimes, signing keys and the claim names your Fineract release reads.

Staff users, roles and permissions

Authentication only proves identity. Fineract's staff users, roles and permissions decide which loan, savings, accounting and administrative actions each person can perform. Map job functions to roles before go-live, keep the number of administrators small, and confirm in the documentation for your version how permissions are named and assigned.

Maker-checker approval flow

Maker-checker separates the person who creates or changes a record from the person who approves it. It is a control banking examiners and auditors look for, and it depends on identities being distinct. Confirm which Fineract actions require approval in your release, whether the maker and checker must be different accounts, and how approvals are logged for audit.

Service and integration API clients

Payment, reporting and CRM integrations call Fineract without a person in the loop, so they need their own identities and credentials. Create dedicated clients with the narrowest permissions the integration needs, store secrets outside code, and plan rotation. Confirm how your release registers such clients and whether their activity appears separately in audit records.

Tenant header and tenants database

Fineract is multi-tenant, and each API request carries a Fineract-Platform-TenantId header that selects tenant connections from the tenants database. An authenticated identity must not be able to reach another tenant by changing this header. Confirm how your release binds tokens or users to tenants and test that cross-tenant calls are refused.

Decisions to settle before configuring identity in Fineract

This table compares the main identity decisions for a Fineract deployment, with the situations where each option fits and the operational cost it carries. Read each row as a choice to make before configuration starts, because later changes to token validation, service accounts or tenant mapping touch many parts of the platform. The main takeaway is that the central identity provider, client identity model and maker-checker scope are hard to reverse once staff and integrations depend on them.

Decision	Option	Trade-off and when it fits
Staff sign-in source	Central external identity provider over OAuth2	Fits institutions that already run corporate identity, joiner-mover-leaver processes and MFA. Costs an integration project and a dependency on the provider being available for sign-in.
Staff sign-in source	Fineract-local users for some staff	Fits a small set of administrators or break-glass accounts. Costs separate password and access reviews, and local accounts are easy to forget when staff leave.
Token validation	Local validation of tokens by Fineract	Fits high API volume where each call should not depend on a provider lookup. Confirm the validation mechanism and key handling for the release in use in the Fineract documentation before designing around it.
Token validation	Introspection by the identity provider	Fits cases where revoked access must take effect quickly. Costs an extra network dependency on each check, so plan for provider latency and outages.
Client identities	Separate identities for people, front end and batch or integration clients	Fits audit requirements that need each action traced to a person or a specific system. Costs more client registrations and a clear owner for each one.
Client identities	Shared service accounts	Fits only very small deployments with a short list of integrations. Costs attribution in audit trails and makes rotation and revocation affect several systems at once.
Maker-checker scope	Limit approval to high-risk actions such as loan disbursement and product changes	Fits teams that want control over money movement and configuration without slowing routine servicing. Costs careful definition of which actions qualify and regular review of that list.
Maker-checker scope	Apply approval to a wider set of staff actions	Fits stricter internal control environments. Costs staff time per approval and more pressure on approvers during batch or month-end peaks.
Approver assignment	Approvers drawn from a defined role separate from the maker's role	Fits segregation of duties expectations. Requires role design that prevents one person holding both maker and checker rights for the same transaction.
Tenant mapping	One identity realm or group per institution	Fits platforms serving several institutions with separate administrators. Costs realm and group administration per tenant and extra mapping logic on each API call.
Tenant mapping	One shared realm with tenant claims or group membership	Fits smaller groups of related brands under one governance model. Costs careful checks that a user can only act on the tenant named in the request.

Build sequence: from default login to governed identity

This sequence replaces Fineract's default development login with an external identity provider, binds every API caller to a governed identity and tenant, and proves that revoked or unauthorized access is refused. Each step closes with a check the team can record as evidence.

Inventory every login path
Before changing anything, list every way a caller reaches Fineract: staff using the web front end, direct API users, integration clients, batch and reporting accounts, and the default development login (mifos) that the project documents for development. For each path, record the owner, the authentication method in use today (OAuth2 or HTTP basic), the tenant it uses, and whether it is still needed. The inventory is complete when every path has a named owner and a keep, change or retire decision, and the team has confirmed that no caller is missing from the list by comparing it against the gateway, reverse proxy and scheduler configuration. Check: the signed-off inventory reconciles with the access logs from a representative period.
Select and register identity clients
Confirm the external identity provider the bank already runs for staff, and decide how it will issue tokens for the front end and for machine clients. The identity team registers the front end as a public or confidential client according to its design, and registers each integration service as a separate client so credentials can be revoked one at a time. Confirm with the identity provider's vendor which OAuth2 grant types and token lifetimes it supports, and record the answers rather than assuming them. Check: each registered client can obtain a token in the non-production environment, and the token carries the expected client identifier and scopes.
Configure Fineract OAuth2 per environment
Set Fineract's OAuth2 and resource server settings for each environment, pointing to that environment's identity provider issuer and keys, and enable HTTPS so tokens never travel in clear text (the documentation strongly encourages HTTPS only and documents SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED). Keep environment-specific values out of images and store secrets in the client's secret manager. Confirm the exact property names against the Fineract version in use, since configuration changes between releases. Check: a valid token from the test identity is accepted, and an request with no token or an expired token is refused over HTTPS.
Enforce the tenant identifier on every call
Fineract is multi-tenant, and API requests carry the Fineract-Platform-TenantId header that selects the tenant connection from the tenants database. Update the front end, the gateway and every integration client so the header is always sent, and confirm that the gateway or a policy layer rejects calls that omit it or name a tenant the caller is not entitled to. Test a token issued for one tenant against another tenant's resources, because a correct token with the wrong tenant is a common gap. Check: cross-tenant requests return a refusal in every test case, and tenant identifiers appear in the audit records for each call.
Disable default and unused basic authentication
Change or remove the default mifos login in every environment that holds real data, and disable HTTP basic authentication on paths that now use OAuth2. Remove unused service accounts and check that no integration still depends on basic credentials by reviewing failed-login logs after the change window opens. Keep a documented, tightly controlled break-glass account only if the bank's policy requires one, with its owner and access procedure recorded. Check: the default login is rejected in each environment, and a scan of the configuration confirms that no basic authentication path remains open except any approved break-glass account.
Define staff roles and maker-checker
Build Fineract's roles and permissions from the job inventory, mapping each job (teller, loan officer, branch manager, accountant, operations approver) to the minimum permissions it needs, rather than copying a template. Then configure maker-checker on the approved actions that the bank's policy requires two people to complete, such as loan disbursement or journal adjustments, and confirm which actions the platform supports natively and which need custom work. Have the business owner sign the role matrix. Check: a test user with a maker role can create a pending action, the same user cannot approve it, and a second authorized user can approve it.
Issue API client credentials with owners
For each integration and batch client, create a dedicated client credential with a named owner, a documented purpose, the tenant it serves, and the narrowest scopes or permissions it needs. Set a rotation plan that states who rotates the secret, how the new value reaches the client without being emailed or pasted into tickets, and how the old value is revoked. Confirm the rotation interval with the bank's security policy and the identity provider's capabilities. Check: every client in the inventory has an owner record, a scope list and a rotation procedure that has been rehearsed once in a non-production environment.
Test the controls with negative cases
Finish with negative testing, because a configuration that only accepts valid users has not been proven. Test that a token from a removed or disabled user is rejected, that a revoked client secret stops working, that a token for one tenant cannot read another, that the default development login fails, that a staff member outside a role cannot reach its endpoints, and that a single user cannot both create and approve a maker-checker action. Record each test case, the expected result and the actual result, and retest after any identity or Fineract configuration change. Check: the test log shows every negative case refused, and the team has filed the evidence with the access control records that the compliance team will need.

What drives identity integration effort and how to keep it down

This table lists the main drivers of SSO and identity integration effort for Apache Fineract, with the reason each one changes the work and the practical steps that keep it manageable. Read each row as a decision to settle before build starts, since most of these drivers multiply when they are discovered late. The main takeaway is that agreeing roles, approvals and environments in writing early usually matters more to effort than the choice of identity provider.

Driver	Why it changes effort	How to keep it down
Distinct staff roles and permission sets	Each role needs a mapped identity group, Fineract permissions and test cases. Permissions multiply quickly when roles are defined per person rather than per job.	Limit the role catalogue to real job functions, reuse existing identity groups where they match, and review the list with branch and operations managers before build.
Tenants or institutions sharing the platform	Each tenant identifier on API calls needs its own role mapping and data scope. Shared staff across tenants add cross-tenant access rules to test.	Confirm which people work across tenants before design, keep one common role set where possible, and document any exceptions in writing.
Existing central identity provider and MFA	Integrating with a provider that already enforces MFA and lifecycle rules is usually less work than building local accounts. Missing or inconsistent MFA adds policy and support effort.	Confirm the identity provider supports OAuth2 and the group claims you need, and check whether MFA policy already covers staff who use Fineract.
API clients and integrations needing non-interactive credentials	Each system account needs its own client registration, scope, secret rotation and owner. Shared or undocumented clients are hard to audit and expensive to fix later.	Inventory every integration before build, issue one client per integration with a named owner, and agree the scopes each client needs.
Maker-checker approval workflows	Each approval type needs configured rules, role separation tests and evidence that the maker and checker were different people. Vague lists cause repeated rework.	Agree the approval list before build, state which actions need a second person, and confirm which Fineract workflows already support maker-checker in the version you run.
Environments (development, test, production, disaster recovery)	Each environment needs its own identity configuration, redirect URLs, secrets and role mappings. Drift between them causes failed test runs and late surprises.	Define configuration as code where possible, use separate identity clients per environment, and test role mapping in staging before production.
Audit evidence auditors will request	Assessors typically ask who had which access, when it changed and how approvals were recorded. Evidence gaps force retrofitting logs and reports.	Agree the evidence list with compliance and internal audit before build, confirm which Fineract and identity provider logs are retained, and set access review schedules.

How identity changes across single node, HA, Kubernetes and air-gapped deployments

With one Fineract instance, identity configuration is the simplest to reason about. The same process validates tokens, serves read and write requests and runs database migrations, so there is one place to check issuer settings, client registrations and certificate expiry. The trade-off is that this instance is also a single point of failure for every staff login and every API client. An identity provider outage or a failed restart stops access to the core system for everyone at once.

Token handling: one issuer, audience and client configuration to test end to end.
Certificates: one TLS endpoint to renew, with HTTPS enabled through the SSL settings in the Fineract documentation.
Login availability: confirm how long a restart takes and whether a maintenance window is acceptable for staff.
Default credentials: confirm the README's default development login is removed before any staff use the system.

Confirm in your environment who can reach the identity provider during a restart, and whether your recovery objectives accept a stopped login path for that period.

Securing identity, credentials and API access in Fineract

Identity controls decide who can reach Fineract, with which credentials, and what each account is allowed to do. The cards below cover the identity-specific steps to complete before any shared environment is exposed. Database and network controls are covered separately in the security hardening topic.

Remove the default development login

The Fineract README ships a development login (username mifos, password password) for OAuth2 and HTTP basic authentication, and it must be changed for any real deployment. Confirm that the default account is disabled or its credentials replaced in every environment, including test and staging, before any shared access is granted. Check the deployment configuration and the database seed data, because a default credential can persist outside the main config file.

Enforce HTTPS and configure SSL

The Fineract documentation strongly encourages HTTPS only. Configure TLS through the documented environment variables, starting with FINERACT_SERVER_SSL_ENABLED, and confirm the setting in each read, write and batch instance. Verify that plain HTTP requests are refused or redirected at the entry point, and that certificate rotation has a documented owner and procedure.

Keep secrets out of images and repositories

OAuth2 client secrets, database passwords and API keys should be injected at runtime from a secrets manager rather than baked into container images or committed to source control. Check the build pipeline, image layers and repository history for stored credentials. Agree who can read each secret, how it is rotated, and how a leaked secret is revoked and replaced.

Apply least privilege to roles

Map each staff role in Fineract to the tasks it needs, and remove permissions that are not required for that job. Review roles that can create clients, post journals or change product configuration, because these carry the highest risk. Record the role matrix as a controlled document and re-check it whenever staff change duties.

Scope batch and integration accounts

Batch jobs, integration consumers and reporting clients usually authenticate as non-human accounts with broad access. Give each one its own identity, a narrow permission set and a named owner. Confirm that these accounts cannot approve their own transactions and that their credentials are separate from staff logins.

Set token lifetimes and revocation

Token lifetimes, refresh behavior and revocation depend on the external identity provider and how it is connected to Fineract. Ask the provider which lifetimes, refresh options and revocation methods it supports, then test that a disabled user or revoked client loses access. Document the expected session length for staff and the procedure for emergency revocation.

Log authentication and approval events

Record login attempts, token issuance, failed authentication, role changes and maker-checker approvals with the user identity and time. Confirm where these logs are stored, who can read them, and how long they are kept. Test that a sample approval can be traced from request to approver, because auditors look for this trail first.

How to verify that Fineract SSO works and fails safely

Verification for Fineract SSO should prove two things before go-live: that staff can sign in through the chosen identity provider and do only what their role allows, and that every failure path closes access instead of opening a fallback. Write these as named test cases with expected results, run them against a non-production tenant that mirrors the production configuration, and keep the results. The tests below are a starting set. Your team should extend them to match the roles and products your institution actually operates. The positive case is a staff member who signs in through the provider and then performs only the actions their role permits. Pick at least one user per role, such as a teller, a loan officer and a branch supervisor, and confirm each can reach the screens and API operations assigned to that role and receives an authorization error for everything else. Check the permission mapping from the identity provider groups to Fineract roles, not only the login itself, because a successful sign-in with an over-broad role is the most common way this goes wrong. The negative cases should show that the default development login does not work once SSO is in place. The default login documented in the Fineract README is mifos with a password that must be changed for any real deployment, so confirm that the account is disabled or its credentials replaced and that basic authentication requests using it are refused. Then test an expired token and a revoked token, which must both be rejected on API calls. Remove a test user from the identity provider and confirm that existing sessions and new token requests stop working within the lifetime your team has set. Send a request without the Fineract-Platform-TenantId header, and a request with a valid token for tenant A that targets tenant B. Both must be refused. The maker-checker tests need a user who creates a request and then attempts to approve it. The maker must not be able to approve their own request. Also confirm that a checker holding the approval permission in a different role, or a user outside the allowed checker role, is refused when they try to approve. Service client tests require a client credential with a scope that is not granted for the operation, which must return an authorization failure. Then test failure behavior: stop the identity provider, attempt sign-in and API access, and confirm that the behavior your team chose holds, whether that is denial with a clear message or a documented break-glass procedure. In every case, the default login must not become the fallback. Record each test with the date, the tester, the build or configuration version, the input, the observed result and a link to the logs or screenshots. This record is the evidence your compliance team will use. DeployOpen can prepare the test scripts, run them and package the evidence for review, but independent auditors decide whether the controls are adequate. Ask your auditor early which evidence format they accept and how long they expect the records to be retained.

What to monitor, rotate, document and review after go-live

Once Fineract accepts logins through an external identity provider, the identity layer needs routine operation: watching sign-in and token behavior, rotating credentials, keeping role records accurate, and retesting after changes. The items below show what the client team owns and what a support agreement can cover.

Monitor failed logins and token errors

Track failed sign-ins, rejected or expired OAuth2 tokens, and unexpected spikes from a single client or tenant. Fineract itself does not give a complete identity view, so pull these signals from the identity provider logs and the Fineract application logs into one place. Agree alert thresholds with the security team, and confirm where the logs are retained and for how long.

Monitor approval activity

Watch maker-checker activity: who submitted changes, who approved them, and whether any user approved a change they created. Look for approvals outside business hours, bursts of approvals on a single account, and checker roles held by staff who should not have them. Confirm with the operations lead which of these events trigger a review and who receives the alert.

Rotate OAuth2 client secrets and API keys

Set a rotation schedule for every OAuth2 client secret and API key used by Fineract integrations, and name one owner for each credential. Rotation needs a short overlap window so integrations can switch without downtime. Confirm with the identity provider vendor how secrets are reissued and whether old secrets can be revoked immediately.

Review joiners, movers and leavers

Run a role review each time a staff member joins, changes team or leaves. Movers are the common failure point: old permissions often stay after a transfer. Remove access in the identity provider and in Fineract, and confirm that deprovisioning also revokes active sessions and tokens. Record who approved each change.

Retest identity after each release

Fineract publishes official releases quarterly, so plan an identity retest after each one. Upgrades can change security configuration, default settings or token handling, so the login, role and approval tests should run again on a staging copy before production. Repeat the same checks after any change to the identity provider, such as a certificate renewal, a new tenant or a changed redirect URI.

Keep the operating records current

Maintain a current role and permission matrix, the maker-checker approval list, a client register of every integration and API client, and a runbook for an identity provider outage. The outage runbook should state how staff reach core functions during the outage, who authorizes emergency access, and how access is restored and reviewed. Client-owned records stay with the institution, while a support agreement can help draft and maintain them.

Questions buyers ask about Fineract SSO and identity integration

How much does it cost to integrate Fineract with an external identity provider?

No price is given here, because cost depends on the written scope. The main cost components are the design of the identity model, the OAuth2 configuration in Fineract and the identity provider, the mapping of your staff roles to Fineract permissions, the maker-checker approval setup, testing, and documentation. Apache Fineract is licensed under Apache-2.0, so there is no license fee, but you still pay for the people who do the work and for the environments that run it. Some costs are one-time, such as the initial build and testing. Others recur, such as reviewing access when staff change roles and applying each quarterly release. A quote should list each of these items separately, state which environments are included, and name what the client must provide. DeployOpen works from a written, fixed scope.

How long does Fineract SSO and identity integration usually take?

The duration depends on how many identity sources, roles and approval paths are involved, and on how quickly your identity team can respond. A single identity provider with a short, agreed role catalogue is a smaller job than several providers with many overlapping roles. Expect time for discovery, for testing role mappings with real staff accounts, and for a security review before production. Ask any provider for a timeline tied to a written scope and to named dependencies, such as identity provider access and approval of the role list. Confirm with your own identity and security teams how long their reviews take, since those steps often set the pace more than the configuration itself.

What must our team provide before the work starts?

Plan to provide four things. First, access to the identity provider, including the ability to register OAuth2 clients and to review its group and claim settings. Second, a role catalogue that lists each staff role, what it may do in Fineract and who approves it. Third, an approval list that names who may approve maker-checker actions, such as loan disbursements or changes to client records, and who may not approve their own work. Fourth, non-production and production environments with a change process, so configuration can be tested before go-live. Also confirm who owns the Fineract admin account, since the README's default development login must be replaced before any real deployment.

Can our own team implement Fineract SSO without outside help?

Yes, if your team has skills in identity federation and in Fineract itself, and if it treats the production warnings in the Fineract README seriously. The README states that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. It also says organizations may pay a vendor for deployment and maintenance. Your team needs to replace default credentials, enable HTTPS only, test token validation, and verify that roles cannot bypass maker-checker controls. If any of these skills are thin, an outside partner can cover the gaps. Ask for the written scope, the test evidence and a handover plan either way.

Does DeployOpen issue certifications for Fineract identity controls?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. DeployOpen can prepare systems, configuration records, access reviews and test evidence so that your auditor has material to assess. Ask your auditor which controls they expect to see for identity, access and approvals before the work starts, so the evidence matches their request. Any statement about a certification should come from the certifying body, not from the implementation partner.

How does identity configuration change with each Fineract release?

The Fineract README states that official releases are created quarterly, at the end of each quarter, following the ASF release policy. Each release can change configuration, API behavior or database migrations, so identity settings need regression testing alongside every upgrade. Check whether a new release changes OAuth2 settings, scopes, role names or permission checks, and test maker-checker flows after each upgrade. Liquibase migrations run only on write instances, so the upgrade plan should cover that step. Keep identity configuration documented and version controlled so a release review does not depend on memory. The support or upgrade agreement should state who tests identity changes after each release.

Which parts of the Fineract identity setup do engineers usually get wrong?

The most common mistakes are leaving default credentials in place, accepting tokens without checking issuer and audience, and mapping broad identity provider groups to powerful Fineract roles. Teams also forget that maker-checker only works if the checker is a different person from the maker, which requires that identity attributes are unique and stable. Verify HTTPS is enforced for every endpoint, test expired and revoked tokens, and confirm that API clients get only the scopes they need. Record each role mapping and review it on a fixed schedule. Use test accounts for each role to confirm that Fineract denies actions outside the role, and keep the results as evidence.

How DeployOpen scopes, builds and hands over Fineract identity work

DeployOpen plans, builds and documents Apache Fineract SSO and identity integration inside your own infrastructure, from OAuth2 with your external identity provider through staff roles, maker-checker approval and API client security. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we scope

We review how staff, API clients and integrations currently authenticate against Fineract, including any default credentials still in place.
We record which identity provider, OAuth2 flows and role mappings your written scope will cover, and which are out of scope.
We agree in writing which maker-checker actions, staff roles and permissions need to be designed and tested before go-live.

How we build

We configure OAuth2 against your external identity provider in a non-production environment, with HTTPS enforced for all Fineract endpoints.
We map identity groups to Fineract roles and permissions, then test each role against the functions it is meant to allow and block.
We set up maker-checker approval flows and API client credentials, and test them with negative cases such as self-approval and expired tokens.

How we hand over

We deliver configuration records, role and permission matrices, and test evidence in a form your security and compliance teams can review.
We document the identity integration runbook, including how to rotate client secrets, add staff accounts and revoke access.
We walk your platform and security staff through the setup and the controls, so your team can operate the integration after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which can cover identity changes after go-live.
Fineract publishes quarterly releases, so we can retest OAuth2 and role behavior against each upgrade you choose to adopt.
Any support scope, response expectations and fees are set in the written agreement, and we will confirm them with you before work starts.