Identity (Centralized Authentication)
Centralized authentication and token issuance based on OAuth and OpenID Connect. Roles and access are deliberately not here; they remain in user and company management.
- Domain
- Platform infrastructure / authentication
- Target customers
- Banks and financial institutions with an admin panel and a customer app at the same time; technical teams adding new services to the platform
- Main capabilities
- Multichannel sign-in (admin/mobile/API), MFA (OTP/TOTP/PIN/Passkey), JWT with asymmetric signing, service-to-service (S2S) authentication, Refresh Token rotation, API key with route scope
Identity is the centralized authentication infrastructure for the whole platform. The service is built on the OAuth 2.0 and OpenID Connect standards (with OpenIddict) and has a single responsibility: establishing the user's identity and issuing tokens. Management of roles and access is deliberately separated from it and entrusted to the UserCompanyManagement service, which is why Identity stays lightweight, independently deployable and replaceable.
Issued tokens are signed with the asymmetric RS256 algorithm using a private key dedicated to this service, and are made available to other services (especially the Gateway) through JWKS, so that validation takes place without direct contact with Identity. Alongside human user sign-in, Identity has a separate channel for machine-to-machine (S2S) authentication with the client_credentials grant type, through which each of the dozens of platform microservices connects to the others with a dedicated client (such as mic.jobspider.s2s or mic.apigateway.s2s) and a limited scope, without a human user's involvement.
Sign-in is supported from several channels: the admin panel (username/password), the customer mobile app with the X-Client-Id identifier (which covers password, PIN, OTP, Passkey/WebAuthn and TOTP), and API keys for programmatic access with a defined route scope. Every successful and failed sign-in, Refresh Token rotation and security event is recorded in dedicated tables, enabling audit and detection of brute-force attacks.
For an enterprise buyer or a bank, the practical meaning is that the sign-in core of all applications (the internal panel, the customer app and communication between services) has a single, auditable source, rather than scattered implementations in each service.
Key capabilities
Multichannel sign-in
Username/password for the admin panel, mobile number/national ID for the customer app, and client identification with X-Client-Id, all from one entry point.
Multi-factor authentication (MFA)
OTP, TOTP, PIN and Passkey/WebAuthn as alternatives or supplements to the password, with automatic discovery of each user's enabled methods.
Refresh token rotation and denylist
Each use of a Refresh Token invalidates the previous token and issues a new one; logout and logout-all (sign-out everywhere) are enforced with a two-level check in Redis.
Asymmetric JWT signing (RS256)
The private key exists only in Identity; other services validate the token with the public key (JWKS) alone, without simultaneous contact with Identity.
Service-to-service (S2S) authentication
Each microservice connects to other services with client_credentials and a dedicated scope; strict issuer/audience validation can be turned on or off.
API key with route scope
For programmatic (integration) access, an API key is issued that can be limited to specific route prefixes (such as only /api/lendtech/).
Brute-force protection and security event logging
A limit on failed sign-in attempts, device session tracking, and full recording of security events for audit.
Multi-company response at sign-in
At sign-in, the list of all companies the user belongs to is returned with the user's role in each, so that company selection is handled in the front-end layer.
Business value
Keeping authentication separate from access management makes it possible to change or tighten sign-in policies (for example, making MFA mandatory) without touching the logic of other services. Asymmetric token signing lets dozens of services validate each request independently, within a few milliseconds, without any extra network call to Identity; this design directly affects the performance and stability of the whole platform under load. A secure S2S channel means that a data leak or failure in one service does not open a path into other services, because each machine-to-machine connection has its own limited scope.
Use cases
- A bank or financial institution with both a staff operations panel and a customer mobile app that wants both to use one secure, auditable sign-in infrastructure.
- Adding a new microservice to the platform that must connect to other services with a limited scope and without human involvement.
- An organization that needs an API key with access limited to specific routes for integration with external systems, without exposing a real user's credentials.
- Cutting off access for all of a user's sessions (for example, after a password leak is suspected) with a single logout-all operation.
Solutions that use this module
See this module on demo data
In a demo session we walk through your organization's scenarios on Dara's demo environment and answer your technical and finance teams' questions.