You can use single sign-on (SSO) to logging on to OceanBase Cloud Platform (OCP) by configuring an external account service that supports Open Authorization 2.0 (OAuth 2.0) or OpenID Connect (OIDC).
Background information
SSO is an identity authentication method, which allows you to securely get authenticated in OCP by using credentials.
Concepts
OAuth is an open standard authorization protocol that allows users to authorize third-party applications to access their protected information stored on resource services without providing the username or password to the third-party applications. This decouples authentication from authorization. OAuth is a widely recognized and used international standard. OAuth 2.0 is an extension to OAuth 1.0. It is more secure and easier to implement. However, it is incompatible with OAuth 1.0. In other words, OAuth 2.0 deprecates OAuth 1.0. OAuth defines a secure, open, and simple standard for authorizing user resources. A third party can obtain the authorization information of users without the need to obtain the user account and password.
- OAuth 2.0 is a delegated authorization framework used for REST/APIs.
- OAuth 2.0 is a token-based authorization protocol that grants applications limited access to user data without disclosing the user password.
- OAuth 2.0 decouples authentication from authorization.
OIDC is a security authentication mechanism. A third-party application connects to the identity provider to request user information and the identity provider returns the information to the application in a secure and reliable manner. OIDC extends the OAuth 2.0 protocol. The ID Token field is added to provide basic user identity information. The ID Token field is encapsulated in the JSON Web Token (JWT) format. An ID token encapsulated in the JWT format is self-contained and provides a tamper-proof mechanism. Therefore, it can be securely transferred to a third-party application and easily verified.
Working mechanism
OAuth 2.0
OCP adapts to the OAuth 2.0 authentication center and supports only the authorization-code mode. In this mode, applications use an authorization code to request an access token or refresh token from the authorization server.
As shown in the preceding figure, the authorization process comprises the following steps:
- The user logs in to the application system. The request is forwarded to the authentication server. Then, the login authentication page appears, with the status code 302 returned.
- The user enters the information required for authentication. After authentication, the authentication server returns an authorization code to the application system.
- The application system sends a request carrying the code to the authentication server to request for an access token. The authentication server verifies the client ID and code and returns an access token to the application system.
- The application system uses the access token to query the user login information. The authentication server returns the user information, such as the username.
- The application system verifies the username, creates a session, and jumps to the redirection URL.
The following table describes the parameters involved in different steps.
| Step |
|
|---|---|
| Step 1 | Authorization Requestresponse_type: required. The value is fixed to code.client_id: required. Specifies the ID of the third-party application.state: recommended. Specifies a string provided by the client. The server will return this string back to the client.redirect_url: required. Specifies the redirection URL after authorization.
NoteIt is the callback URL used by the authorization server to call the OCP service. If the SSO system has a callback allowlist, you must add the URL to the allowlist. scope: optional. Specifies the authorization scope. |
| Step 2 | Parameters passed in Step 1 are verified. The login authentication page appears. You need to specify the resources accessible to the client. |
| Step 3 | Authorization Response The authorization server jumps to the redirection URL specified in Step 1 and returns the following information: code: specifies the authorization code.state: specifies the state parameter provided by the client in Step 1. |
| Step 4 | Access Token Requestgrant_type: required. The value is fixed to authorization_code.code: required. Specifies the response code in Authorization Response.redirect_url: required. Specifies the redirection URL. The value must be the same as the redirection URL provided in Authorization Request.client_id: required. Specifies the client ID. The value must be the same as the client ID provided in Authorization Request. |
| Step 5 | Access Token Response access_token: specifies the access token.refresh_token: optional. Specifies the refresh token.expires_in: specifies the expiration time. |
OIDC
- The client sends an authentication request to the authentication service.
- The user confirms authorization on the authentication page.
- The authentication service verifies the authentication request and returns a code to the client.
- The client requests a callback API from the business service, carrying the code in the request.
- The business service requests a token from the authentication service, carrying the code, client ID, and client secret in the request.
- The authentication service verifies the information carried in the request and returns an ID token to the business service.
- After authentication, the business service returns the ID token to the client.
- The client initiates a business request, carrying the ID token in the request.
- The business service verifies the ID token and returns a response to the client.
Login scenarios
- When SSO and local login are enabled, you can log in by using an OCP account or a third-party account.
- When SSO is enabled but local login is disabled, you can directly log in to OCP by using a third-party account. When you log in for the first time, you will be redirected to the authorization page of the third-party application. After you complete authorization, you can directly log in with the account.
- When SSO is disabled, you can only directly log in to OCP by using an OCP account.
View the SSO integration task list
If you log in as the ADMIN or ADMIN_VIEWER role, you can view detailed SSO integration configurations in OCP, including the configuration name, type, creation time, last modification time, creator, and whether local login is enabled. You can also perform general O&M operations. For more information, see Create an SSO integration task, Enable/Disable an SSO integration task, Edit an SSO integration task, and Delete an SSO integration task.