import OidcCallbackUri from '@/mdx-components/OidcCallbackUri';
import Step from '@/mdx-components/Step';

<Step index={0} title="Create an OIDC application on your IdP">

Initiate the OIDC SSO integration by creating an application on the IdP side. You will need to provide the following configurations from the Logto server.

- **Callback URI**: The Logto Callback URI, also known as the Redirect URI or Reply URL, is a specific endpoint or URL that the IdP uses to redirect the user's browser after successful authentication. After a user successfully authenticates with the IdP, the IdP redirects the user's browser back to this designated URI along with an authorization code. Logto will complete the authentication process based on authorization code received from this URI.

<OidcCallbackUri />

Fill in the Logto Callback URI in your IdP OIDC application settings form and continue to create the application.(Most of the OIDC IdPs provides a wide range of application types to choose from. To create a web based SSO connector on Logto, please choose the `Web Application` type.)

</Step>
<Step index={1} title="Configure OIDC SSO on Logto">

After successfully creating an OIDC application on the IdP side, you will need to provide the IdP configurations back to Logto. Navigate to the `Connection` tab, and fill in the following configurations:

- **Client ID**: A unique identifier assigned to your OIDC application by the IdP. This identifier is used by Logto to identify and authenticate the application during the OIDC flow.

- **Client Secret**: A confidential secret shared between Logto and the IdP. This secret is used to authenticate the OIDC application and secure the communication between Logto and the IdP.

- **Issuer**: The issuer URL, a unique identifier for the IdP, specifying the location where the OIDC identity provider can be found. It is a crucial part of the OIDC configuration as it helps Logto discover the necessary endpoints.

  To make the configuration process easier. Logto will automatically fetch the required OIDC endpoints and configurations. This is done by utilizing the issuer you provided and making a call to the IdP's OIDC discover endpoints. It is imperative to ensure that the issuer endpoint is valid and accurately configured to enable Logto to retrieve the required information correctly.

  After a successful fetch request, you should be able to see the parsed IdP configurations under the issuers section.

</Step>

<Step index={2} title="Configure scopes">
Scopes define the permissions your app requests from users and control which data your app can access from their enterprise accounts.

Setting up scopes requires configuration on both sides:

1. **Your Identity Provider (IdP)**: Configure which permissions are allowed for authorization in your IdP console
   - Some IdPs enable all public scopes by default (no action needed)
   - Others require you to explicitly grant permissions
2. **Logto enterprise connector**: Specify which scopes to request during authentication in the Logto OIDC enterprise connector settings > `Scopes` field.
   - Logto always includes the `openid`, `profile`, and `email` scopes to retrieve basic user identity information, regardless of your custom scope settings.
   - You can add additional scopes (separated by spaces) to request more information from the IdP.
</Step>

<Step index={3} title="Store tokens to access third-party APIs (Optional)">
If you want to access the Identity Provider's APIs and perform actions with user authorization, Logto needs to get specific API scopes and store tokens.

1. Add the required scopes in the **scope** field following the instructions above
2. Enable **Store tokens for persistent API access** in the Logto OIDC enterprise connector. Logto will securely [store access tokens in the Secret Vault](https://docs.logto.io/secret-vault/federated-token-set).
3. For **standard** OIDC identity providers, the `offline_access` scope must be included to obtain a refresh token, preventing repeated user consent prompts.
</Step>

<Step index={4} title="Set email domains and enable the SSO connector">

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 exclusively limited to use your SSO connector as their only authentication method.

</Step>
