In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with .NET Core (Razor Pages) and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of .NET Core (Razor Pages).
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Traditional web application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Traditional web" section or filter all the available "Traditional web" frameworks using the quick filter checkboxes on the left. Click the ".NET Core (Razor Pages)" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate .NET Core (Razor Pages) with Logto​

Installation​

Add the NuGet package to your project:

dotnet add package Logto.AspNetCore.Authentication

Add Logto authentication​

Open Startup.cs (or Program.cs) and add the following code to register Logto authentication services:

using Logto.AspNetCore.Authentication;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddLogtoAuthentication(options =>
{
  options.Endpoint = builder.Configuration["Logto:Endpoint"]!;
  options.AppId = builder.Configuration["Logto:AppId"]!;
  options.AppSecret = builder.Configuration["Logto:AppSecret"];
});

The AddLogtoAuthentication method will do the following things:

• Set the default authentication scheme to LogtoDefaults.CookieScheme.
• Set the default challenge scheme to LogtoDefaults.AuthenticationScheme.
• Set the default sign-out scheme to LogtoDefaults.AuthenticationScheme.
• Add cookie and OpenID Connect authentication handlers to the authentication scheme.

Sign-in and sign-out flows​

Before we proceed, there are two confusing terms in the .NET Core authentication middleware that we need to clarify:

1. CallbackPath: The URI that Logto will redirect the user back to after the user has signed in (the "redirect URI" in Logto)
2. RedirectUri: The URI that will be redirected to after necessary actions have been taken in the Logto authentication middleware.

The sign-in process can be illustrated as follows:

Similarly, .NET Core also has SignedOutCallbackPath and RedirectUri for the sign-out flow.

For the sake of clarity, we'll refer them as follows:

Configure redirect URIs​

First, let's configure the Logto redirect URI. Add the following URI to the "Redirect URIs" list in the Logto application details page:

http://localhost:3000/Callback

To configure the Logto post sign-out redirect URI, add the following URI to the "Post sign-out redirect URIs" list in the Logto application details page:

http://localhost:3000/SignedOutCallback

Change the default paths​

The Logto redirect URI has a default path of /Callback, and the Logto post sign-out redirect URI has a default path of /SignedOutCallback.

You can leave them as are if there's no special requirement. If you want to change it, you can set the CallbackPath and SignedOutCallbackPath property for LogtoOptions:

builder.Services.AddLogtoAuthentication(options =>
{
  // Other configurations...
  options.CallbackPath = "/Foo";
  options.SignedOutCallbackPath = "/Bar";
});

Remember to update the value in the Logto application details page accordingly.

Implement sign-in/sign-out buttons​

First, add the handler methods to your PageModel, for example:

public class IndexModel : PageModel
{
  public async Task OnPostSignInAsync()
  {
    await HttpContext.ChallengeAsync(new AuthenticationProperties
    {
      RedirectUri = "/"
    });
  }

  public async Task OnPostSignOutAsync()
  {
    await HttpContext.SignOutAsync(new AuthenticationProperties
    {
      RedirectUri = "/"
    });
  }
}

Then, add the buttons to your Razor page:

<p>Is authenticated: @User.Identity?.IsAuthenticated</p>
<form method="post">
  @if (User.Identity?.IsAuthenticated == true) {
    <button type="submit" asp-page-handler="SignOut">Sign out</button>
  } else {
    <button type="submit" asp-page-handler="SignIn">Sign in</button>
  }
</form>

It will show the "Sign in" button if the user is not authenticated, and show the "Sign out" button if the user is authenticated.

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with .NET Core (Razor Pages) as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your .NET Core (Razor Pages) app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with Expo (React Native) and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of Expo (React Native).
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Native app application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Native app" section or filter all the available "Native app" frameworks using the quick filter checkboxes on the left. Click the "Expo" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Expo with Logto​

Installation​

Install Logto SDK and peer dependencies via your favorite package manager:

npm i @logto/rn
npm i expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

yarn add @logto/rn
yarn add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

pnpm add @logto/rn
pnpm add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

The @logto/rn package is the SDK for Logto. The remaining packages are its peer dependencies. They couldn't be listed as direct dependencies because the Expo CLI requires that all dependencies for native modules be installed directly within the root project's package.json.

Init Logto provider​

Import and use LogtoProvider to provide a Logto context:

import { LogtoProvider, LogtoConfig } from '@logto/rn';

const config: LogtoConfig = {
  endpoint: '<your-logto-endpoint>',
  appId: '<your-application-id>',
};

const App = () => (
  <LogtoProvider config={config}>
    <YourAppContent />
  </LogtoProvider>
);

Implement sign-in and sign-out​

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Switch to the application details page of Logto Console. Add a native redirect URI (for example, io.logto://callback), then click "Save".

• For iOS, the redirect URI scheme does not really matter since the ASWebAuthenticationSession class will listen to the redirect URI regardless of if it's registered.

• For Android, the redirect URI scheme must be filled in Expo's app.json file, for example:

  app.json

  {
    "expo": {
      "scheme": "io.logto"
    }
  }
  

Now back to your app, you can use useLogto hook to sign in and sign out:

import { useLogto } from '@logto/rn';
import { Button } from 'react-native';

const Content = () => {
  const { signIn, signOut, isAuthenticated } = useLogto();

  return (
    <div>
      {isAuthenticated ? (
        <Button title="Sign out" onPress={async () => signOut()} />
      ) : (
        // Replace the redirect URI with your own
        <Button title="Sign in" onPress={async () => signIn('io.logto://callback')} />
      )}
    </div>
  );
};

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with Expo as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your Expo (React Native) app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with Express and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of Express.
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Traditional web application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Traditional web" section or filter all the available "Traditional web" frameworks using the quick filter checkboxes on the left. Click the "Express" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Express with Logto​

Installation​

Install Logto SDK via your favorite package manager:

npm i @logto/express cookie-parser express-session

pnpm add @logto/express cookie-parser express-session

yarn add @logto/express cookie-parser express-session

Integration​

Prepare configs and required middlewares​

Prepare configuration for the Logto client:

import { LogtoExpressConfig } from '@logto/express';

const config: LogtoExpressConfig = {
  appId: '<your-application-id>',
  appSecret: '<your-application-secret>',
  endpoint: '<your-logto-endpoint>', // E.g. http://localhost:3001
  baseUrl: '<your-express-app-base-url>', // E.g. http://localhost:3000
};

The SDK requires express-session to be configured in prior.

import cookieParser from 'cookie-parser';
import session from 'express-session';

app.use(cookieParser());
app.use(
  session({
    secret: 'random_session_key', // Replace with your own secret
    cookie: { maxAge: 14 * 24 * 60 * 60 * 1000 }, // In miliseconds
  })
);

Configure redirect URIs​

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Configure redirect URIs​

Switch to the application details page of Logto Console. Add a redirect URI http://localhost:3000/callback.

Just like signing in, users should be redirected to Logto for signing out of the shared session. Once finished, it would be great to redirect the user back to your website. For example, add http://localhost:3000/ as the post sign-out redirect URI section.

Then click "Save" to save the changes.

Register routes​

The SDK provides a helper function handleAuthRoutes to register 3 routes:

1. /logto/sign-in: Sign in with Logto.
2. /logto/sign-in-callback: Handle sign-in callback.
3. /logto/sign-out: Sign out with Logto.

Add the following code to your app:

import { handleAuthRoutes } from '@logto/express';

app.use(handleAuthRoutes(config));

Implement sign-in and sign-out​

With the routes registered, now let's implement the sign-in and sign-out buttons in the home page. We need to redirect the user to the sign-in or sign-out route when needed. To help with this, use withLogto to inject authentication status to req.user.

import { withLogto } from '@logto/express';

app.get('/', withLogto(config), (req, res) => {
  res.setHeader('content-type', 'text/html');

  if (req.user.isAuthenticated) {
    res.end(`<div>Hello ${req.user.claims?.sub}, <a href="/logto/sign-out">Sign Out</a></div>`);
  } else {
    res.end('<div><a href="/logto/sign-in">Sign In</a></div>');
  }
});

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with Express as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your Express app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with Flutter and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of Flutter.
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Native app application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Native app" section or filter all the available "Native app" frameworks using the quick filter checkboxes on the left. Click the "Flutter" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Flutter with Logto​

Installation​

flutter pub add logto_dart_sdk

dependencies:
  logto_dart_sdk: ^3.0.0

flutter pub get

git clone https://github.com/logto-io/dart

Dependency and configurations​

SDK version compatibility​

flutter_secure_storage set up​

Under the hood, this SDK uses flutter_secure_storage to implement the cross-platform persistent secure token storage.

• Keychain is used for iOS
• AES encryption is used for Android.

Config Android version​

Set the android:minSdkVersion to >= 18 in your project's android/app/build.gradle file.

  android {
      ...

      defaultConfig {
          ...
          minSdkVersion 18
          ...
      }
  }

Disable auto backup on Android​

By default Android backups data on Google Drive. It can cause exception java.security.InvalidKeyException:Failed to unwrap key. To avoid this,

1. To disable auto backup, go to your app manifest file and set the android:allowBackup and android:fullBackupContent attributes to false.

   AndroidManifest.xml

   <manifest ... >
       ...
       <application
         android:allowBackup="false"
         android:fullBackupContent="false"
         ...
       >
           ...
       </application>
   </manifest>
   
   

2. Exclude sharedprefs from FlutterSecureStorage.

   If you need to keep the android:fullBackupContent for your app rather than disabling it, you can exclude the sharedprefs directory from the backup. See more details in the Android documentation.

   In your AndroidManifest.xml file, add the android:fullBackupContent attribute to the <application> element, as shown in the following example. This attribute points to an XML file that contains backup rules.

   AndroidManifest.xml

   <application ...
     android:fullBackupContent="@xml/backup_rules">
   </application>
   

   Create an XML file called @xml/backup_rules in the res/xml/ directory. In this file, add rules with the <include> and <exclude> elements. The following sample backs up all shared preferences except device.xml:

   @xml/backup_rules

   <?xml version="1.0" encoding="utf-8"?>
   <full-backup-content>
     <exclude domain="sharedpref" path="FlutterSecureStorage"/>
   </full-backup-content>
   

Please check flutter_secure_storage for more details.

flutter_web_auth_2 set up​

Behind the scenes, this SDK uses flutter_web_auth_2 to authenticate users with Logto. This package provides a simple way to authenticate users with Logto using the system webview or browser.

This plugin uses ASWebAuthenticationSession on iOS 12+ and macOS 10.15+, SFAuthenticationSession on iOS 11, Chrome Custom Tabs on Android and opens a new window on Web.

• iOS: No additional setup required

• Android: Register the callback url on Android

  In order to capture the callback url from Logto's sign-in web page, you will need to register your sign-in redirectUri to your AndroidManifest.xml file.

  AndroidManifest.xml

    <manifest>
      <application>
          <activity
            android:name="com.linusu.flutter_web_auth_2.CallbackActivity"
            android:exported="true">
            <intent-filter android:label="flutter_web_auth_2">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="YOUR_CALLBACK_URL_SCHEME_HERE" />
            </intent-filter>
          </activity>
      </application>
    </manifest>
  

• Web browser: Create an endpoint to handle the callback URL

  If you are using the web platform, you need to create an endpoint to handle the callback URL and send it back to the application using the postMessage API.

  callback.html

  <!doctype html>
  <title>Authentication complete</title>
  <p>Authentication is complete. If this does not happen automatically, please close the window.</p>
  <script>
    function postAuthenticationMessage() {
      const message = {
        'flutter-web-auth-2': window.location.href,
      };
  
      if (window.opener) {
        window.opener.postMessage(message, window.location.origin);
        window.close();
      } else if (window.parent && window.parent !== window) {
        window.parent.postMessage(message, window.location.origin);
      } else {
        localStorage.setItem('flutter-web-auth-2', window.location.href);
        window.close();
      }
    }
  
    postAuthenticationMessage();
  </script>
  

Please check the setup guide in the flutter_web_auth_2 package for more details.

Integration​

Init LogtoClient​

Import the logto_dart_sdk package and initialize the LogtoClient instance at the root of your application.

import 'package:logto_dart_sdk/logto_dart_sdk.dart';
import 'package:http/http.dart' as http;

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      title: 'Flutter Demo',
      home: MyHomePage(title: 'Logto Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);
  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  late LogtoClient logtoClient;

  void render() {
    // state change
  }

  // LogtoConfig
  final logtoConfig = const LogtoConfig(
    endpoint: "<your-logto-endpoint>",
    appId: "<your-app-id>"
  );

  void _init() {
    logtoClient = LogtoClient(
      config: logtoConfig,
      httpClient: http.Client(), // Optional http client
    );
    render();
  }

  @override
  void initState() {
    super.initState();
    _init();
  }

  // ...
}

Implement sign-in​

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Before starting, you need to add a redirect URI in the Admin Console for your application.

Let's switch to the Application details page of Logto Console. Add a Redirect URI io.logto://callback and click "Save changes".

• For iOS, the redirect URI scheme does not really matter since the ASWebAuthenticationSession class will listen to the redirect URI regardless of if it's registered.
• For Android, the redirect URI scheme must be registered in the AndroidManifest.xml file.

After the redirect URI is configured, we add a sign-in button to your page, which will call logtoClient.signIn API to invoke the Logto sign-in flow:

class _MyHomePageState extends State<MyHomePage> {
  // ...
  final redirectUri = 'io.logto://callback';

  @override
  Widget build(BuildContext context) {
    // ...

    Widget signInButton = TextButton(
      onPressed: () async {
        await logtoClient.signIn(redirectUri);
        render();
      },
      child: const Text('Sign In'),
    );

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            signInButton,
          ],
        ),
      ),
    );
  }
}

Implement sign-out​

Let's switch to the Application details page of Logto Console. Add a Post Sign-out Redirect URI io.logto://callback and click "Save changes".

Post Sign-outRedirect URI is an OAuth 2.0 concept which implies the location should redirect after signing out.

Now let's add a sign-out button on the main page so users can sign out from your application.

class _MyHomePageState extends State<MyHomePage> {
  // ...

  final postSignOutRedirectUri = 'io.logto//home';

  @override
  Widget build(BuildContext context) {
    // ...

    Widget signOutButton = TextButton(
      onPressed: () async {
        await logtoClient.signOut(postSignOutRedirectUri);
        render();
      },
      child: const Text('Sign Out'),
    );

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            signInButton,
            signOutButton,
          ],
        ),
      ),
    );
  }
}

Handle authentication status​

Logto SDK provides an asynchronous method to check the authentication status. The method is logtoClient.isAuthenticated. The method returns a boolean value, true if the user is authenticated, otherwise false.

In the example we conditionally render the sign-in and sign-out buttons based on the authentication status. Now let's update the render method in our Widget to handle the state change:

class _MyHomePageState extends State<MyHomePage> {
  // ...
  bool? isAuthenticated = false;

  void render() {
    setState(() async {
      isAuthenticated = await logtoClient.isAuthenticated;
    });
  }

  @override
  Widget build(BuildContext context) {
    // ...

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            SelectableText('My Demo App'),
            isAuthenticated == true ? signOutButton : signInButton,
          ],
        ),
      ),
    );
  }
}

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with Flutter as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your Flutter app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with Go and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of Go.
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Traditional web application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Traditional web" section or filter all the available "Traditional web" frameworks using the quick filter checkboxes on the left. Click the "Go" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Go with Logto​

Installation​

Execute in the project root directory:

# Install the core package for accessing predefined values and types
go get github.com/logto-io/go/v2/core

# Install the client package for interacting with the Logto
go get github.com/logto-io/go/v2/client

Add github.com/logto-io/go/v2/core and github.com/logto-io/go/v2/client packages to your application code:

// main.go
package main

import (
	"github.com/gin-gonic/gin"
	// Add dependency
	"github.com/logto-io/go/v2/core"
	"github.com/logto-io/go/v2/client"
)

func main() {
	router := gin.Default()
	router.GET("/", func(c *gin.Context) {
		c.String(200, "Hello Logto!")
	})
	router.Run(":3000")
}

Create a session storage​

In traditional web applications, the user authentication information will be stored in the user session.

Logto SDK provides a Storage interface, you can implement a Storage adapter based on your web framework so that the Logto SDK can store user authentication information in the session.

The Storage type in the Logto SDK is as follows:

package client

type Storage interface {
	GetItem(key string) string
	SetItem(key, value string)
}

We use github.com/gin-contrib/sessions middleware as an example to demonstrate this process.

Apply the middleware to the application, so that we can get the user session by the user request context in the route handler:

package main

import (
	"github.com/gin-contrib/sessions"
	"github.com/gin-contrib/sessions/memstore"
	"github.com/gin-gonic/gin"
	"github.com/logto-io/go/v2/client"
)

func main() {
	router := gin.Default()

	// We use memory-based session in this example
	store := memstore.NewStore([]byte("your session secret"))
	router.Use(sessions.Sessions("logto-session", store))

	router.GET("/", func(ctx *gin.Context) {
		// Get user session
		session := sessions.Default(ctx)
		// ...
		ctx.String(200, "Hello Logto!")
	})
	router.Run(":3000")
}

Create a session_storage.go file, define a SessionStorage and implement the Logto SDK's Storage interfaces:

package main

import (
	"github.com/gin-contrib/sessions"
)

type SessionStorage struct {
	session sessions.Session
}

func (storage *SessionStorage) GetItem(key string) string {
	value := storage.session.Get(key)
	if value == nil {
		return ""
	}
	return value.(string)
}

func (storage *SessionStorage) SetItem(key, value string) {
	storage.session.Set(key, value)
	storage.session.Save()
}

Now, in the route handler, you can create a session storage for Logto:

session := sessions.Default(ctx)
sessionStorage := &SessionStorage{session: session}

Init LogtoClient​

First, create a Logto config:

func main() {
	// ...
	logtoConfig := &client.LogtoConfig{
		Endpoint:  "<your-logto-endpoint>", // E.g. http://localhost:3001
		AppId:     "<your-application-id>",
		AppSecret: "<your-application-secret>",
	}
	// ...
}

astuce:

You can find and copy "App Secret" from application details page in Admin Console:

Then, you can create a LogtoClient for each user request with the Logto config above:

func main() {
	// ...

	router.GET("/", func(ctx *gin.Context) {
		// Create LogtoClient
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// Use Logto to control the content of the home page
		authState := "You are not logged in to this website. :("

		if logtoClient.IsAuthenticated() {
			authState = "You are logged in to this website! :)"
		}

		homePage := `<h1>Hello Logto</h1>` +
			"<div>" + authState + "</div>"

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// ...
}

Implement sign-in route​

After the redirect URI is configured, we add a sign-in route to handle the sign-in request and also add an sign-in link on the home page:

func main() {
	// ...

	// Add a link to perform a sign-in request on the home page
	router.GET("/", func(ctx *gin.Context) {
		// ...
		homePage := `<h1>Hello Logto</h1>` +
			"<div>" + authState + "</div>" +
			// Add link
			`<div><a href="/sign-in">Sign In</a></div>`

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// Add a route for handling sign-in requests
	router.GET("/sign-in", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// The sign-in request is handled by Logto.
		// The user will be redirected to the Redirect URI on signed in.
		signInUri, err := logtoClient.SignIn("http://localhost:3000/callback")
		if err != nil {
			ctx.String(http.StatusInternalServerError, err.Error())
			return
		}

		// Redirect the user to the Logto sign-in page.
		ctx.Redirect(http.StatusTemporaryRedirect, signInUri)
	})

	// ...
}

Now, when your user visit http://localhost:3000/sign-in, the user will be redirected to the Logto sign-in page.

Implement the callback route​

When the user signs in successfully on the Logto sign-in page, Logto will redirect the user to the Redirect URI.

Since the redirect URI is http://localhost:3000/callback, we add the /callback route to handle the callback after signing in.

func main() {
	// ...

	// Add a route for handling sign-in callback requests
	router.GET("/callback", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// The sign-in callback request is handled by Logto
		err := logtoClient.HandleSignInCallback(ctx.Request)
		if err != nil {
			ctx.String(http.StatusInternalServerError, err.Error())
			return
		}

		// Jump to the page specified by the developer.
		// This example takes the user back to the home page.
		ctx.Redirect(http.StatusTemporaryRedirect, "/")
	})

	// ...
}

Implement sign-out route​

Similar to the sign-in flow, when the user signs out, Logto will redirect the user to the post sign-out redirect URI.

Now, let's add the sign-out route to handle the sign-out request and also add a sign-out link on the home page:

func main() {
	// ...

	// Add a link to perform a sign-out request on the home page
	router.GET("/", func(ctx *gin.Context) {
		// ...
		homePage := `<h1>Hello Logto</h1>` +
			"<div>" + authState + "</div>" +
			`<div><a href="/sign-in">Sign In</a></div>` +
			// Add link
			`<div><a href="/sign-out">Sign Out</a></div>`

		ctx.Data(http.StatusOK, "text/html; charset=utf-8", []byte(homePage))
	})

	// Add a route for handling signing out requests
	router.GET("/sign-out", func(ctx *gin.Context) {
		session := sessions.Default(ctx)
		logtoClient := client.NewLogtoClient(
			logtoConfig,
			&SessionStorage{session: session},
		)

		// The sign-out request is handled by Logto.
		// The user will be redirected to the Post Sign-out Redirect URI on signed out.
		signOutUri, signOutErr := logtoClient.SignOut("http://localhost:3000")

		if signOutErr != nil {
			ctx.String(http.StatusOK, signOutErr.Error())
			return
		}

		ctx.Redirect(http.StatusTemporaryRedirect, signOutUri)
	})

	// ...
}

After the user makes a signing-out request, Logto will clear all user authentication information in the session.

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with Go as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your Go app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with iOS (Swift) and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of iOS (Swift).
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Native app application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Native app" section or filter all the available "Native app" frameworks using the quick filter checkboxes on the left. Click the "iOS (Swift)" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate iOS (Swift) with Logto​

Add Logto SDK as a dependency​

Use the following URL to add Logto SDK as a dependency in Swift Package Manager.

https://github.com/logto-io/swift.git

Since Xcode 11, you can directly import a Swift package w/o any additional tool.

We do not support Carthage and CocoaPods at the time due to some technical issues.

Init LogtoClient​

Initialize the client by creating a LogtoClient instance with a LogtoConfig object.

import Logto
import LogtoClient

let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // E.g. http://localhost:3001
  appId: "<your-app-id>"
)
let client = LogtoClient(useConfig: config)

let config = try? LogtoConfig(
  // ...
  usingPersistStorage: false
)

Sign in​

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Configure redirect URI​

Let's switch to the Application details page of Logto Console. Add a Redirect URI io.logto://callback and click "Save changes".

Sign-in and sign-out​

You can use client.signInWithBrowser(redirectUri:) to sign in the user and client.signOut() to sign out the user.

For example, in a SwiftUI app:

struct ContentView: View {
  @State var isAuthenticated: Bool

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            await client.signOut()
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: "${
                props.redirectUris[0] ?? 'io.logto://callback'
              }")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // error occured during sign in
            } catch {
              // other errors
            }
          }
        }
      }
    }
  }
}

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with iOS (Swift) as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.

2. Click "Add enterprise connector" button and choose your SSO provider type. Choose from prebuilt connectors for Microsoft Entra ID (Azure AD), Google Workspace, and Okta, or create a custom SSO connection using the standard OpenID Connect (OIDC) or SAML protocol.
3. Provide a unique name (e.g., SSO sign-in for Acme Company).

4. Configure the connection with your IdP in the "Connection" tab. Check the guides above for each connector types.

5. Customize the SSO experience and enterprise’s email domain in the "Experience" tab. Users sign in with the SSO-enabled email domain will be redirected to SSO authentication.

6. Save changes.

Set up OIDC application on Okta admin portal​

Step 1: Create an OIDC application on Okta admin portal​

• Visit the Okta admin portal and sign in as an administrator.
• Navigate to the Applications/Applications page using the side menu.
• Click the Create App Integration button to create a new OIDC application.
• Select the OIDC - OpenID Connect option as the Sign-in method.
• Select the Web Application option as the Application type.

Click the Next button to continue.

Step 2: Configure the application settings​

1. Provide an App integration name. It will be used as the identifier of your OIDC application.
2. Add a new Sign-in redirect URIs using the Logto SSO connector's callback URL.

This is the URI that the Okta will 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 the authorization code received from this URI.

3. Assign users to the application.

Based on the Assignments settings, you can choose to assign the application to all users or specific users/groups.

Click the Save button to save the application settings.

Step 3: Set up Logto connector with the client credentials​

After successfully creating the OIDC application, you will be redirected to the application details page.

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.

Step 4: Additional scopes (Optional)​

Scopes define the permissions your app requests from users and control which data your app can access from their Okta accounts. Requesting additional Okta permissions requires configuration on both sides:

In Okta admin console:

1. Navigate to Applications > Applications and select your OIDC application.
2. Go to the Assignments tab to ensure your app has access to the required users and groups.
3. For custom scopes, navigate to Security > API > Authorization Servers and select your authorization server.
4. Add custom scopes if needed:
   • Click Scopes and then Add Scope
   • Define scope names like okta.users.read or okta.groups.read for accessing Okta APIs
   • Configure consent requirements for each scope

For a complete list of available scopes and their descriptions, please refer to the Okta OIDC documentation.

In Logto Okta connector:

1. Logto automatically includes openid, profile, and email scopes to retrieve basic user identity information. You can leave the Scopes field blank if you only need basic user information.
2. Add offline_access to the Scopes field if you plan to store tokens for persistent API access. This scope enables refresh tokens for long-lived API access.
3. Add additional scopes (separated by spaces) in the Scopes field to request more data from Okta. For example: okta.users.read okta.groups.read

Step 5: Store tokens to access Okta APIs (Optional)​

If you want to access Okta scopes and perform actions with user authorization, Logto needs to get specific scopes and store tokens.

1. Add the required scopes in your Okta developer console API permissions configuration and Logto Okta connector.
2. Enable Store tokens for persistent API access in Logto Okta connector. Logto will securely store Okta access and refresh tokens in the Secret Vault.
3. To ensure refresh tokens are returned, add the offline_access scope to your Okta application permissions and include it in your Logto Okta connector scopes. This scope allows your application to maintain access to resources for extended periods.

Step 6: Set email domains and enable the SSO connector​

Provide the email domains of your organization on Logto's connector SSO 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 redirected to use your SSO connector as their only authentication method.

For more details about creating OIDC integration with Okta, please check Create OIDC App Integrations.

Save your configuration​

Double check you have filled out necessary values in the Logto connector configuration area. Click "Save and Done" (or "Save changes") and the Okta enterprise SSO connector should be available now.

Enable Okta enterprise SSO connector in Sign-in Experience​

You don’t need to configure enterprise connectors individually, Logto simplifies SSO integration into your applications with just one click.

1. Navigate to: Console > Sign-in & account > Sign-up and sign-in.
2. Enable the "Enterprise SSO" toggle.
3. Save changes.

Once enabled, a "Single Sign-On" button will appear on your sign-in page. Enterprise users with SSO-enabled email domains can access your services using their enterprise identity providers (IdPs).

To learn more about the SSO user experience, including SP-initiated SSO and IdP-initiated SSO, refer to User flows: Enterprise SSO.

Testing and Validation​

Return to your iOS (Swift) app. You should now be able to sign in with Okta enterprise SSO. Enjoy!

Further readings​

End-user flows: Logto provides a out-of-the-box authentication flows including MFA and enterprise SSO, along with powerful APIs for flexible implementation of account settings, security verification, and multi-tenant experience.

Authorization: Authorization defines the actions a user can do or resources they can access after being authenticated. Explore how to protect your API for native and single-page applications and implement Role-based Access Control (RBAC).

Organizations: Particularly effective in multi-tenant SaaS and B2B apps, the organization feature enable tenant creation, member management, organization-level RBAC, and just-in-time-provisioning.

Customer IAM series Our serial blog posts about Customer (or Consumer) Identity and Access Management, from 101 to advanced topics and beyond.

In this article, we will go through the steps to quickly build the Okta enterprise SSO sign-in experience (user authentication) with Next.js (Pages Router) and Logto.

Prerequisites

• A running Logto instance. Check out the introduction page to get started.
• Basic knowledge of Next.js (Pages Router).
• A usable Okta enterprise SSO account.

Create an application in Logto​

Logto is based on OpenID Connect (OIDC) authentication and OAuth 2.0 authorization. It supports federated identity management across multiple applications, commonly called Single Sign-On (SSO).

To create your Traditional web application, simply follow these steps:

1. Open the Logto Console. In the "Get started" section, click the "View all" link to open the application frameworks list. Alternatively, you can navigate to Logto Console > Applications, and click the "Create application" button.
2. In the opening modal, click the "Traditional web" section or filter all the available "Traditional web" frameworks using the quick filter checkboxes on the left. Click the "Next.js" framework card to start creating your application.
3. Enter the application name, e.g., "Bookstore," and click "Create application".

🎉 Ta-da! You just created your first application in Logto. You'll see a congrats page which includes a detailed integration guide. Follow the guide to see what the experience will be in your application.

Integrate Next.js with Logto​

Installation​

Install Logto SDK via your favorite package manager:

npm i @logto/next

pnpm add @logto/next

yarn add @logto/next

Integration​

Init LogtoClient​

Import and initialize LogtoClient:

import LogtoClient from '@logto/next';

export const logtoClient = new LogtoClient({
  appId: '<your-application-id>',
  appSecret: '<your-app-secret-copied-from-console>',
  endpoint: '<your-logto-endpoint>', // E.g. http://localhost:3001
  baseUrl: 'http://localhost:3000',
  cookieSecret: 'complex_password_at_least_32_characters_long',
  cookieSecure: process.env.NODE_ENV === 'production',
});

Configure Redirect URIs​

Before we dive into the details, here's a quick overview of the end-user experience. The sign-in process can be simplified as follows:

1. Your app invokes the sign-in method.
2. The user is redirected to the Logto sign-in page. For native apps, the system browser is opened.
3. The user signs in and is redirected back to your app (configured as the redirect URI).

Configure redirect URIs​

Switch to the application details page of Logto Console. Add a redirect URI http://localhost:3000/api/logto/sign-in-callback.

Just like signing in, users should be redirected to Logto for signing out of the shared session. Once finished, it would be great to redirect the user back to your website. For example, add http://localhost:3000/ as the post sign-out redirect URI section.

Then click "Save" to save the changes.

Prepare API routes​

Prepare API routes to connect with Logto.

Go back to your IDE/editor, use the following code to implement the API routes first:

import { logtoClient } from '../../../libraries/logto';

export default logtoClient.handleAuthRoutes();

This will create 4 routes automatically:

1. /api/logto/sign-in: Sign in with Logto.
2. /api/logto/sign-in-callback: Handle sign-in callback.
3. /api/logto/sign-out: Sign out with Logto.
4. /api/logto/user: Check if user is authenticated with Logto, if yes, return user info.

Implement sign-in and sign-out​

We have prepared the API routes, now let's implement the sign-in and sign-out buttons in your home page. We need to redirect the user to the sign-in or sign-out route when needed. To help with this, use useSWR to fetch authentication status from /api/logto/user.

Check this guide to learn more about useSWR.

import { type LogtoContext } from '@logto/next';
import useSWR from 'swr';

const Home = () => {
  const { data } = useSWR<LogtoContext>('/api/logto/user');

  return (
    <nav>
      {data?.isAuthenticated ? (
        <p>
          Hello, {data.claims?.sub},
          <button
            onClick={() => {
              window.location.assign('/api/logto/sign-out');
            }}
          >
            Sign Out
          </button>
        </p>
      ) : (
        <p>
          <button
            onClick={() => {
              window.location.assign('/api/logto/sign-in');
            }}
          >
            Sign In
          </button>
        </p>
      )}
    </nav>
  );
};

export default Home;

Checkpoint: Test your application​

Now, you can test your application:

1. Run your application, you will see the sign-in button.
2. Click the sign-in button, the SDK will init the sign-in process and redirect you to the Logto sign-in page.
3. After you signed in, you will be redirected back to your application and see the sign-out button.
4. Click the sign-out button to clear token storage and sign out.

Add Okta enterprise SSO connector​

To simplify access management and gain enterprise-level safeguards for your big clients, connect with Next.js as a federated identity provider. The Logto enterprise SSO connector helps you establish this connection in minutes by allowing several parameter inputs.

To add an enterprise SSO connector, simply follow these steps:

1. Navigate to Logto console > Enterprise SSO.