Cloud-native API Gateway integrates with your enterprise's authentication system through the OpenID Connect (OIDC) protocol, providing centralized authentication and authorization for internal services. This eliminates repetitive per-service integration, enables single sign-on (SSO), and supports flexible security policy configuration.
Prerequisites
You have a unified authorization server that supports the standard OIDC protocol.
Background information
As the entry point for external access to internal services, the API gateway authenticates and authorizes incoming requests to protect backend services. Cloud-native API Gateway integrates with your self-managed authentication system through the OIDC protocol, enabling unified authentication for all connected services without per-service integration.
OIDC authentication
OIDC is an authentication protocol that enables third-party applications to verify end user identities through an identity provider. Built on OAuth 2.0, OIDC adds an ID Token — a self-contained, tamper-proof JSON Web Token (JWT) that carries basic user identity information and can be securely transmitted to and verified by third-party applications.
A typical OIDC flow involves the following four roles:
client: An application that provides services directly to the end user.
authorization server: An OpenID provider that issues ID Tokens to third-party applications for authentication.
business server: A server that provides business services.
end user: The resource owner who grants access to their information.
The workflow is as follows:
The client sends an authentication request to the authorization server.
The end user grants authorization on the authentication page, typically by logging in with a username and password.
The authorization server validates the authentication request and returns an authorization code to the client.
The client sends a request to a callback endpoint on the business server, including the authorization code.
The business server requests a token from the authorization server. The request includes the authorization code, client ID, and client secret.
The authorization server validates the request and returns an ID Token.
After successful authentication, the business server returns the ID Token to the client.
The client makes a business request that includes the ID Token.
The business server validates the ID Token and returns a business response.
Gateway OIDC authentication flow
In the preceding OIDC flow, each business server (such as a user service or order service) must implement its own authentication logic and integrate with the authorization server. Cloud-native API Gateway centralizes this at the gateway level, eliminating per-service authentication code.
The workflow is as follows:
The client sends an authentication request to the gateway.
The gateway sends an authentication request to the authorization server.
The authorization server returns a code to the gateway.
The gateway returns the code to the client.
The client sends a callback request with the code to the gateway.
The gateway exchanges the code for a token with the authorization server.
The authorization server returns an ID Token to the gateway.
The gateway returns an authentication success response to the client and sets a cookie.
The client initiates a business request carrying the cookie, and the gateway verifies the token.
The gateway forwards the business request carrying the ID Token to the business service.
The business server's response is returned to the client through the gateway.
During this process, Cloud-native API Gateway validates each request. Invalid requests trigger a redirect to the login page, where the gateway proxies the authorization server to handle authentication. This makes the authorization server transparent to backend business servers.
Create an authentication and authorization rule
Log on to the API Gateway console.
In the left-side navigation pane, click . In the top navigation bar, select a region.
On the Instance page, click the name of the target gateway instance.
In the left-side navigation pane, choose .
In the upper-left corner of the page, click Create Authentication. Configure the gateway authentication parameters and click OK.
The following table describes the parameters for OIDC authentication.
Parameter
Description
Enable
Specifies whether to enable authentication for the Cloud-native API Gateway instance.
Authentication Name
The custom name for the authentication rule.
Authentication Type
Select OIDC.
Domain Name
The domain name to which the authentication rule applies.
Issuer
The issuer URL of the authorization server.
Redirect URL
The URL where the end user is redirected after successful authorization. This URL must match the one configured in your OIDC identity provider.
ImportantThe URL must be in the format
http(s)://yourdomain/pathand the path must be/oauth2/callback.Client ID
The client ID of your application registered with the identity provider.
Client secret
The client secret of your application registered with the identity provider.
Cookie domain
The domain for the session cookie. After the end user is authenticated, the cookie is sent to this domain to maintain the login session. For example, if you set the cookie domain to
a.example.com, the cookie is sent to thea.example.comdomain. If you set the cookie domain to.example.com, the cookie is sent to all subdomains ofexample.com.Cookie secret
A secret used to digitally sign the session cookie to prevent it from being tampered with.
Scope
Specify the scopes of authorization. You can add multiple scopes, separated by semicolons (;).
Authorization
Select the authorization mode. You can choose either Whitelist Mode or Blacklist Mode.
whitelist: Requests to hosts and paths in the whitelist can bypass authentication. All other requests require it.
blacklist: Only requests to hosts and paths in the blacklist require authentication. All other requests can pass through without it.
Click Rule Condition to set the request domain names and paths.
Domain Name: The request host.
Path: The request API path.
Authentication and authorization details
Log on to the API Gateway console.
In the left-side navigation pane, click . In the top navigation bar, select a region.
On the Instance page, click the name of the target gateway instance.
In the left-side navigation pane, choose .
On the Global Authentication page, click an authentication rule name, or click Description in the Actions column. You can view the current Authentication Configuration and Authorization Information.
The details page contains three sections. Basic Information displays the name and source. Authentication Configuration displays fields such as issuer, client ID, Cookie domain, redirect URL, client secret, and scope. Authorization Information displays the current authorization mode (whitelist or blacklist). Multiple rule conditions have an OR relationship, while multiple matching items within a single rule condition have an AND relationship.
In the Authorization Information section, you can click Create Authorization. In the dialog box that appears, enter a Request Domain Name and Request Path, select a Match Mode, then click OK to add a new authorization rule.
Verify the result
Return to the Global Authentication page. If the rule you created appears in the list, the rule was created successfully.
Related operations
You can also manage gateway authentication rules as follows:
-
Enable an authentication rule: On the Global Authentication page, find the target authentication rule and click Enable in the Actions column.
-
Disable an authentication rule: On the Global Authentication page, find the target authentication rule and click Close in the Actions column.
-
Edit an authentication rule: On the Global Authentication page, find the target authentication rule and click Edit in the Actions column.
-
Delete an authentication rule: On the Global Authentication page, find the target authentication rule and click Delete in the Actions column.
You must disable an authentication rule before you can delete it.
Related documentation
To learn about other authentication mechanisms, see Global Authentication.