From 527cd226087ad027750301694f710119c0f13b3d Mon Sep 17 00:00:00 2001 From: simeng-li Date: Fri, 1 Dec 2023 19:33:02 +0800 Subject: [PATCH] feat(console): update content (#5035) * feat(console): update content update content * fix(console): fix the layout fix the layout --- .../docs/single-sign-on/AzureAD/README.mdx | 6 ++--- .../single-sign-on/GoogleWorkspace/README.mdx | 22 +++++++++++-------- .../docs/single-sign-on/OIDC/README.mdx | 2 +- .../docs/single-sign-on/OKTA/README.mdx | 20 +++++++++++++---- .../docs/single-sign-on/SAML/README.mdx | 2 +- 5 files changed, 34 insertions(+), 18 deletions(-) diff --git a/packages/console/src/assets/docs/single-sign-on/AzureAD/README.mdx b/packages/console/src/assets/docs/single-sign-on/AzureAD/README.mdx index a6b213f6a..39807c6b0 100644 --- a/packages/console/src/assets/docs/single-sign-on/AzureAD/README.mdx +++ b/packages/console/src/assets/docs/single-sign-on/AzureAD/README.mdx @@ -66,7 +66,7 @@ Logto will fetch the metadata from the URL and configure the SAML SSO integratio Logto provides a flexible way to map the user attributes returned from IdP to the user attributes in Logto. Logto will sync the following user attributes from IdP by default: -- id: The unique identifier of the user. Logto will read the `nameId` claim from the SAML response as the user SSO identity id. +- id: The unique identifier of the user. Logto will read the `nameID` claim from the SAML response as the user SSO identity id. - email: The email address of the user. Logto will read the `email` claim from the SAML response as the user primary email by default. - name: The name of the user. @@ -78,7 +78,7 @@ You may manage the user attributes mapping logic either on the Azure AD side or Copy the following attribute names (with namespace prefix) and paste them into the corresponding fields in Logto. - - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email` + - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` (Recommendation: update this attribute value map to `user.displayname` for better user experience) @@ -118,7 +118,7 @@ Visit the `Users and groups` section of your Azure AD SSO application. Click on -Provide the email domains of your organization at the Logto's SAML SSO connector experience tab. This will enable the SSO connector as an authentication method for those users. +Provide the email `domains` of your organization at the Logto's SAML SSO connector `experience` tab. This will enable the SSO connector as an authentication method for those users. Users with email addresses in the specified domains will be restricted to use SAML SSO connector as their only authentication method. diff --git a/packages/console/src/assets/docs/single-sign-on/GoogleWorkspace/README.mdx b/packages/console/src/assets/docs/single-sign-on/GoogleWorkspace/README.mdx index def6bd889..879e5adaf 100644 --- a/packages/console/src/assets/docs/single-sign-on/GoogleWorkspace/README.mdx +++ b/packages/console/src/assets/docs/single-sign-on/GoogleWorkspace/README.mdx @@ -17,11 +17,7 @@ Before you can use Google Workspace as an authentication provider, you must set -In order to create a new OIDC credential, you need to configure the consent screen for your application. Otherwise, you will receive an error prompt when creating the credential like the following: - -
- create credentials -
+In order to create a new OIDC credential, you need to configure the consent screen for your application. 1. Navigate to the [OAuth consent screen](https://console.cloud.google.com/apis/credentials/consent) page and select the `Internal` user type. This will make the OAuth application only available to users within your organization. @@ -80,7 +76,7 @@ Continue set up the OAuth credential by filling up the following information: - + After successfully creating the OAuth credential, you will receive a prompt modal with the client ID and client secret. @@ -88,15 +84,23 @@ After successfully creating the OAuth credential, you will receive a prompt moda client credentials -Copy the client ID and client secret and fill in the corresponding fields on the Logto SSO connector connection page. +Copy the `client ID` and `client secret` and fill in the corresponding fields on the Logto SSO connector `connection` tab. Now you have successfully configured a Google Workspace SSO connector on Logto. - + -Provide the email domains of your organization on the connector experience tab. This will enabled the SSO connector as an authentication method for those users. +Use the `Scope` field to add additional scopes to your OAuth request. This will allow you to request for more information from the Google OAuth server. Please refer to the [Google OAuth Scopes](https://developers.google.com/identity/protocols/oauth2/scopes) documentation for more information. + +\*Regardless of the custom scope settings, Logto will always send the `openid`, `profile` and `email` scopes to the IdP. This is to ensure that Logto can retrieve the user's identity information and email address properly. + + + + + +Provide the email `domains` of your organization on the connector `experience` tab. This will enabled the SSO connector as an authentication method for those users. Users with email addresses in the specified domains will be restricted to use your SSO connector as their only authentication method. diff --git a/packages/console/src/assets/docs/single-sign-on/OIDC/README.mdx b/packages/console/src/assets/docs/single-sign-on/OIDC/README.mdx index d25907844..56a8ca7c0 100644 --- a/packages/console/src/assets/docs/single-sign-on/OIDC/README.mdx +++ b/packages/console/src/assets/docs/single-sign-on/OIDC/README.mdx @@ -35,7 +35,7 @@ After successfully creating an OIDC application on the IdP side, you will need t -Provide the email domains of your organization on the connector experience tab. This will enabled the SSO connector as an authentication method for those users. +Provide the email `domains` of your organization on the connector `experience` tab. This will enabled the SSO connector as an authentication method for those users. Users with email addresses in the specified domains will be restricted to use your SSO connector as their only authentication method. diff --git a/packages/console/src/assets/docs/single-sign-on/OKTA/README.mdx b/packages/console/src/assets/docs/single-sign-on/OKTA/README.mdx index a21deea02..977f916fb 100644 --- a/packages/console/src/assets/docs/single-sign-on/OKTA/README.mdx +++ b/packages/console/src/assets/docs/single-sign-on/OKTA/README.mdx @@ -48,7 +48,7 @@ Click the `Save` button to save the application settings. - + After successfully creating the OIDC application, you will be redirected to the application details page. @@ -56,13 +56,25 @@ After successfully creating the OIDC application, you will be redirected to the client credentials -Copy the client ID and client secret and fill in the corresponding fields on the Logto SSO connector connection page to complete the configuration. +Copy the `client ID` and `client secret` and fill in the corresponding fields on the Logto SSO connector `connection` tab. + +Use your Okta domain as the `issuer`. Example: `https://dev-12345678.okta.com`. Once you have filled in all the fields, click the `Save` button to save the connector settings. + +If the `issuer` link you provided is valid, you will see a parsed full list of Okta IdP configurations shown below the `issuer` field. - + -Provide the email domains of your organization on the connector experience tab. This will enabled the SSO connector as an authentication method for those users. +Use the `Scope` field to add additional scopes to your OAuth request. This will allow you to request for more information from the Okta OAuth server. Please refer to the [Okta documentation](https://developer.okta.com/docs/reference/api/oidc/#scopes) for more details about the available scopes. + +\*Regardless of the custom scope settings, Logto will always send the `openid`, `profile` and `email` scopes to the IdP. This is to ensure that Logto can retrieve the user's identity information and email address properly. + + + + + +Provide the email `domains` of your organization on the connector `experience` tab. This will enabled the SSO connector as an authentication method for those users. Users with email addresses in the specified domains will be restricted to use your SSO connector as their only authentication method. diff --git a/packages/console/src/assets/docs/single-sign-on/SAML/README.mdx b/packages/console/src/assets/docs/single-sign-on/SAML/README.mdx index c95214d7a..8eea78ed3 100644 --- a/packages/console/src/assets/docs/single-sign-on/SAML/README.mdx +++ b/packages/console/src/assets/docs/single-sign-on/SAML/README.mdx @@ -49,7 +49,7 @@ The user attributes returned from IdP may vary depending on the IdP configuratio -Provide the email domains of your organization in the SAML SSO integration experience tab. This will enable the SSO connector as an authentication method for those users. +Provide the email `domains` of your organization in the SAML SSO integration `experience` tab. This will enable the SSO connector as an authentication method for those users. Users with email addresses in the specified domains will be restricted to use SAML SSO connector as their only authentication method.