Token Service
Apinizer can work as an identity provider service in addition to authorization. Clients can generate tokens using Apinizer's token generation service with their credentials. They can send the generated tokens within the message and perform authentication and authorization through these tokens instead of their own credentials.
Apinizer runs on two separate planes, and the token endpoints belong to the API Gateway:
- API Manager (control plane). The administrative component where all configuration is made — API proxies, credentials, policies, settings. The Management API and APIops endpoints run here. The Manager is not exposed to the outside world; only administrators use it, to apply configuration changes. It is off the request hot path.
- API Gateway (data plane). The high-performance runtime that processes every API request. The token endpoints run here, not on the Manager. They are open to client access: a client calls them to obtain a token and then uses that token to reach the proxied APIs. Because the Gateway carries production traffic, it is typically placed behind a load balancer and scaled horizontally.
In short: configuration changes go to the Manager (APIops); token acquisition and API access go to the Gateway (token API). The two are deliberately separated — the Manager stays private and administrative, while the token API is reachable by clients.
The data flow between the client and Apinizer is shown simply in the following image:
Apinizer stores tokens generated for OAuth2 authentication in its own database and also caches them for performance.
In JWT authentication, Apinizer does not need any token storage area for token validation. Instead, it stores the RSA key belonging to the Worker in each environment. The token is validated by checking the RSA key with which the JWT token was generated. This check only verifies that the token was generated by Apinizer and that the data has not been corrupted or changed (remains as generated). In addition to this validation, the policy also checks the "claim" values within the token according to the API Proxy information from which the message came.
Apinizer prefers generating JWT tokens through API calls rather than sharing the key value with the client.
Although the key value is often shared for generating JWT token values, Apinizer prefers generating JWT tokens through API calls with a new approach at this point. Thus, it makes token generation and key management easier for clients instead of key control and sharing. In this approach, standard parameters requested in OAuth2 are requested in the JWT token generation API and processed similarly.
To view the description of the JWT token acquisition and OAuth2 token acquisition panel, you can visit the Token Acquisition Methods page.
When acquiring tokens with JWT or OAuth2, if "Manage From This Policy" is selected, the CORS and XFF settings configured from the "Settings" tab of the API Proxy will be valid.
However, if this option is not checked, if it is managed through "Credentials", the CORS and XFF settings you added to the Worker in "Gateway Environments" will be valid. See.
Related Pages
- Token Introspection, Revocation and Discovery — Inspect, revoke, and discover token endpoints
- Gateway Token Endpoints — Full endpoint reference with request/response details