When multiple backend services each implement their own authentication logic, you face duplicated code, inconsistent security policies, and complex maintenance. A cloud-native gateway solves this by centralizing OpenID Connect (OIDC) authentication at the gateway layer -- the gateway handles token validation, session management, and login redirects so that backend services receive only pre-authenticated requests. This strengthens system security and provides a more flexible security policy configuration. Single sign-on (SSO) is also supported across all services behind the gateway.
Prerequisites
Before you begin, make sure that you have:
An identity provider (IdP) that supports the standard OIDC protocol
The following information from your IdP:
| Item | Description |
|---|---|
| Issuer URL | The base URL for the .well-known/openid-configuration discovery endpoint. The gateway uses this URL to automatically retrieve the IdP's authorization, token, and userinfo endpoints. |
| Client ID | The application identifier assigned during IdP registration |
| Client secret | The application secret assigned during IdP registration |
| Redirect URL | A callback URL registered in the IdP. The path must be /oauth2/callback. Format: https://yourdomain/oauth2/callback |
OIDC authentication flow
Standard OIDC flow
In a standard OIDC setup, four roles interact:
| Role | Description |
|---|---|
| Client | The application that serves end users (for example, a browser or mobile app) |
| Authorization server | The OpenID provider that authenticates users and issues ID tokens |
| Business server | The backend service that provides business logic |
| End user | The resource owner -- the person who accesses the application |
OIDC extends OAuth 2.0 by adding an ID token -- a JSON Web Token (JWT) that carries user identity information in a self-contained, tamper-proof format.
The standard flow works as follows:
The client sends an authentication request to the authorization server.
The end user enters credentials on the authorization page and confirms the request.
The authorization server validates the request and returns an authorization code to the client.
The client sends a callback request with the authorization code to the business server.
The business server sends the authorization code, client ID, and client secret to the authorization server.
The authorization server validates the request and returns an ID token.
The business server forwards the ID token to the client.
The client includes the ID token in subsequent business requests to the business server.
The business server validates the ID token and returns a business response.
In this model, each business server must independently connect to the authorization server to validate tokens -- creating duplicated integration effort.
Gateway-based OIDC flow
When a cloud-native gateway handles OIDC authentication, the gateway replaces the business server in the token exchange. The authorization server becomes transparent to backend services -- they only receive pre-validated requests.
The gateway-based flow works as follows:
The client sends a request to the gateway.
The gateway redirects the client to the authorization server.
The authorization server authenticates the user and returns an authorization code to the gateway.
The gateway sends the authorization code back to the client.
The client sends a callback request with the authorization code to the gateway.
The gateway sends the authorization code, client ID, and client secret to the authorization server.
The authorization server validates the request and returns an ID token.
The gateway sends the ID token to the client.
The client includes the ID token in subsequent business requests to the gateway.
The gateway validates the ID token and forwards the request to the appropriate backend service.
The backend service processes the request and returns a response to the gateway.
The gateway forwards the response to the client.
For unauthenticated or invalid requests, the gateway automatically redirects the client to the authorization server's login page.
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 gateway ID.
In the left-side navigation pane, choose Security Management > Global Authentication.
In the upper-left corner of the page that appears, click Create Authentication. In the Create Authentication panel, configure the following parameters, and then click OK.
| Parameter | Description |
|---|---|
| Authentication Name | A name for the authentication rule. |
| Authentication Type | Select OIDC. |
| Issuer | The issuer identifier from your IdP. This is the base URL used for OIDC discovery (the .well-known/openid-configuration endpoint). |
| Redirect URL | The URL that the authorization server redirects to after authentication completes. Format: http(s)://yourdomain/oauth2/callback. The path must be /oauth2/callback, and this URL must match the redirect URL registered in your IdP. |
| Client-ID | The application ID from your IdP's registration information. |
| Client-Secret | The application secret from your IdP's registration information. |
| Cookie-Domain | The domain to which the session cookie is sent after authentication. Set to a.example.com to send the cookie only to that specific host, or .example.com to send it to all subdomains of example.com. |
| Scope | The OIDC scopes to request. Separate multiple values with semicolons (;). |
| Authorization | The access control mode: Whitelist -- Only requests matching specified hostnames and paths bypass authentication. All other requests require authentication. Blacklist -- Only requests matching specified hostnames and paths require authentication. All other requests bypass authentication. Click + Rule Condition to add entries. For each entry, specify a Domain Name and a Path. |
Create an authentication route
After the authentication rule is created, create a route to handle the OIDC callback. For step-by-step instructions, see Create a routing rule.
Configure the following parameters for the authentication route:
| Parameter | Value |
|---|---|
| Domain Name | Select the domain name from the Redirect URL of the authentication rule. If no domain name is configured, select *. |
| Path | Select Prefix and enter /oauth2. |
| Destination Service | Set to oauth2-proxy. |
For HTTPS requests, configure a domain name and associate it with the route.
Verify the authentication rule
Return to the Global Authentication page. If the new authentication rule appears in the list, the configuration is complete.
View authentication rule 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 gateway ID.
In the left-side navigation pane, choose Security Management > Global Authentication.
Click the name of an authentication rule, or click Details in the Actions column. The details page shows the current authentication configuration and authorization information.
In the Authorization Information section, click Add Authorization Information to add new entries. Specify the Request Domain Name, Request Path, and matching mode, and then click OK.
Manage authentication rules
On the Global Authentication page, find the target authentication rule and use the following actions in the Actions column:
| Action | Description |
|---|---|
| Enable | Activate the authentication rule. |
| Disable | Deactivate the authentication rule. |
| Edit | Modify the authentication rule settings. |
| Delete | Remove the authentication rule. You must disable the rule before deletion. |
References
For an overview of all supported authentication mechanisms, see Gateway authentication overview.