Unified Service Gateway (ApiGateway)
The only public entry to the microservices. It authenticates each request and sends it to the right destination; routes are built from the live service discovery list.
- Domain
- Platform infrastructure / Edge and network security
- Target customers
- The organization's technical and security teams; integration partners (API/limited access key); IT managers responsible for traffic audit
- Main capabilities
- Dynamic routing from Eureka, JWT/API Key validation, secure user-header rebuilding, token blacklist, Rate Limiting, centralized documentation portal
ApiGateway is the only public entry point to all of the platform's microservices. The service is built on YARP (Yet Another Reverse Proxy), and it authenticates, enriches and routes every incoming request to the correct target service. Routes behind the Gateway are built from Eureka's live list, and not from a fixed configuration file. That means no backend address is written in appsettings, and adding a new service needs no manual change to routes in the Gateway (each service publishes its own route segment in its Eureka registration metadata, and the Gateway reads it within about 30 seconds).
The Gateway's authentication layer reads the JWT token or API key, rebuilds the user headers (User-Id, Company-Id, roles, Tenant ID and so on) from scratch (to prevent header forgery by the client), and forwards them to the target service. Every downstream service sees these headers as valid and ready to use, with no need to validate the token again. Token blacklist checking (logout and logout-all) and selection of the user's current company (from among the companies they are permitted) are also done in this same layer, and not in each service separately.
The Gateway also hosts a centralized documentation portal (Scalar/Swagger at the /docs path) that aggregates the OpenAPI documentation of all services and, based on each user's access, shows only the documentation of the services they are allowed to see. From an enterprise buyer's point of view, ApiGateway means a single security and operational control point for the whole platform, instead of every customer or team having to talk separately to dozens of backend services.
Key capabilities
Dynamic routing from Eureka
No backend address is in fixed configuration. A new service added to the registration list is detected and routed automatically.
Token and API key validation
Accepts both JWT (with JWKS from Identity) and API keys with a path scope, at a single point.
Secure rebuilding of user headers
Before forwarding, every header arriving from the client is stripped and rebuilt from the token's valid claims, which prevents identity forgery.
Two-level token blacklist check
Both a specific token and all of a user's tokens (after logout-all) are rejected in this layer, before reaching the target service.
Current company selection and validation
If the user has not selected a company, their first permitted company is selected automatically. Selecting a company outside the user's permitted list is rejected.
Rate limiting
General protection against excessive load, along with a dedicated limit for the documentation portal's sign-in page.
Centralized documentation portal
Aggregates the OpenAPI of all services behind one page, with access control based on the user's actual permissions in each service.
Specific, limited public paths
Only a small list of paths (such as sign-in, profile image, public logo) pass through the Gateway without a token. Everything else is always authenticated.
Business value
Routing based on automatic service discovery (Eureka) means that adding or moving a backend service happens without stopping or redeploying the Gateway. This directly reduces the setup time of new services and the operational cost of maintaining the platform. Concentrating token validation, header rebuilding and blacklist checking in one layer, instead of repeating them in every service, gives a more uniform level of security and also makes it simpler to maintain, because a change in security policy is applied at only one point.
Use cases
- A new service developed by an independent team goes live the same day, available behind the public address /api/{service-name}/ without coordinating with the Gateway team.
- Providing programmatic access to a business partner with an API key limited to only one or a few specific services.
- A security review or audit that needs to show that all incoming traffic passes through a single control point.
- Immediately blocking all sessions of a suspicious user at the Gateway level, with no change needed in any backend service.
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.