By integrating your enterprise's authentication system with the OpenID Connect (OIDC) protocol, you can manage authentication and authorization for your internal services centrally. This approach simplifies the authentication process and reduces repetitive integration efforts. Cloud-native Gateway provides unified authentication to enhance system security and offers flexible security policy configurations. Integrating OIDC also enables single sign-on (SSO), allowing you to access multiple services with a single login.
本文适用于云原生网关普通实例标准版、普通实例专业版。
Prerequisites
You must have a unified authentication service that supports the standard OIDC protocol.
Background information
As a control point for external access to internal services, a gateway must authenticate external requests to ensure the security of internal services. Enterprises typically build a unified, self-managed authentication system. Cloud-native Gateway can connect to such systems by using the OIDC protocol. This allows the gateway to provide unified authentication for all connected internal services, eliminating the need to connect each service to the authentication system individually.
OIDC authentication
OIDC is an identity layer on top of the OAuth 2.0 protocol. It allows third-party applications to connect to an identity provider to obtain user information and have it returned securely. OIDC extends OAuth 2.0 with an ID Token, which is a JSON Web Token (JWT). The ID Token encapsulates basic user identity information in a self-contained and tamper-proof format, which can be securely transmitted to and easily verified by third-party applications.
The following roles are formalized in OIDC:
Client: An application that provides services directly to the user.
Authorization server: An OpenID provider, which is an authorization server that issues ID Tokens for authentication.
Business server: The server that hosts the protected resources or services.
User: The resource owner who grants access.
The workflow is as follows:
The client sends an authentication request to the authorization server.
The user confirms the authorization on the authentication page, typically by logging in with a username and password.
The authorization server validates the request and returns an authorization code to the client.
The user is redirected to the client's callback endpoint, which receives the authorization code.
The client requests a token from the authorization server, sending the authorization code, client ID, and client secret.
The authorization server validates the request and returns an ID Token.
After successful authentication, the client receives the ID Token and can proceed with authenticated requests.
The client makes a request to the business server, including the ID Token.
The business server validates the ID Token and returns a response.
OIDC authentication flow with Cloud-native Gateway
In the standard OIDC flow, if you have multiple business services, such as a user service and an order service, each service must implement its own authentication logic. This includes validating requests and integrating with the authorization server. By using the OIDC authentication feature of Cloud-native Gateway, you can centralize this authentication logic at the gateway level.
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.
Throughout the entire process, Cloud-native Gateway validates requests. If a request is invalid, the gateway redirects the user to a login page and proxies the authentication process with the authorization server. This process is transparent to the backend business services.
Create an authentication rule
-
Log on to the MSE console.
-
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
-
On the Gateways page, click the ID of the gateway.
-
In the left-side navigation pane, choose Security Management > Global Authentication.
In the upper-left corner of the page, click Create Authentication, configure the gateway authentication parameters, and then click OK.
The following table describes the OIDC authentication parameters for Cloud-native Gateway.
Parameter
Description
Authentication Name
A custom name for the authentication rule.
Authentication Type
Select OIDC.
Issuer
The issuer URI of your authorization server.
Redirect URL
The URL where the user is redirected after a successful authorization. This URL must match the one registered with your OIDC identity provider.
ImportantThe URL must be in the format
http(s)://yourdomain/path. 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 cookie. After authentication is successful, the cookie is sent to the specified domain to maintain the login state. For example, if you set
Cookie-domain=a.example.com, the cookie is sent to the domain a.example.com. If you setCookie-domain=.example.com, the cookie is sent to all subdomains of example.com.Scope
Specifies the requested authorization scopes. Use a semicolon (
;) to separate multiple scopes.Grant
The authorization mode. The supported modes are Whitelist and Blacklist.
Whitelist: Requests that match the hosts and paths in the whitelist bypass authentication. All other requests require authentication.
Blacklist: Requests that match the hosts and paths in the blacklist require authentication. All other requests are accessed directly.
Click + Rule condition to set the request domain and path.
Domain Name: The requested domain name, or host.
Path: The requested API path.
Create an authentication route
After creating the authentication rule, you must create a related route. For more information, see Create a route.
Configure the route parameters as follows:
Domain Name: Select the domain from the Redirect URL that you configured in the authentication rule. If no domain is configured, you can select *.
ImportantIf you use HTTPS, you must configure and associate a domain.
Path: Select Prefix Match and enter
/oauth2.Destination Service: Select oauth2-proxy.
View authentication details
-
Log on to the MSE console.
-
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
-
On the Gateways page, click the ID of the gateway.
-
In the left-side navigation pane, choose Security Management > Global Authentication.
On the Global Authentication page, click the name of an authentication rule or click Details in the Actions column to view the current Authentication Configuration and manage the Authorization Information.
The authentication configuration details page has three sections: The Basic Information section displays the name and source. The Authentication Configuration section displays fields such as Issuer, Redirect URL, Client ID, Client secret, Cookie domain, and Scope. The Authorization Information section displays the authorization mode, such as whitelist mode. You can click Create authorization information to add request domain and request path matching rules. An OR relationship exists among multiple rule conditions.
In the Authorization Information section, click Add Authorization Information. In the dialog box that appears, enter a Request Domain Name and Request Path, select a Match Mode, and then click OK to add a new authorization rule.
Verify the results
Return to the Global Authentication page. If the new authentication rule appears in the list, it was created successfully.
Related operations
You can also perform the following operations to manage your authentication rules:
-
Enable an authentication rule: On the Global Authentication page, find the target rule and click Enable in the Actions column. This activates the rule.
-
Disable an authentication rule: On the Global Authentication page, find the target rule and click Close in the Actions column. This deactivates the rule.
-
Edit an authentication rule: On the Global Authentication page, find the target rule and click Edit in the Actions column to modify its configuration.
-
Delete an authentication rule: On the Global Authentication page, find the target rule and click Delete in the Actions column to permanently remove it.
You must disable an authentication rule before you can delete it.
Related topics
To learn about other authentication mechanisms, see Global Authentication.