メインコンテンツまでスキップ
Cloud availabilityOSS availability

IdP-initiated SSO (SAML のみ)

IdP-initiated SSO は、アイデンティティプロバイダー (IdP) が主に認証フローを制御するシングルサインオンプロセスです。このプロセスは、ユーザーが会社のポータルや中央のアイデンティティダッシュボードなど、IdP のプラットフォームにログインすることで始まります。認証 (Authentication) が完了すると、IdP は SAML アサーションを生成し、ユーザーをサービスプロバイダー (SP) にリダイレクトしてアプリケーションやサービスにアクセスさせます。

IdP-initiated SSO

リスクと考慮事項

IdP-initiated SSO は、組織が認識しておくべきいくつかのセキュリティ脆弱性を引き起こす可能性があります。認証 (Authentication) プロセスがユーザーからの直接の要求なしに IdP によって開始されるため、クロスサイトリクエストフォージェリ (CSRF) などのさまざまな攻撃に対して脆弱になる可能性があります。

ユーザーが開始しない認証 (Authentication) は、適切な保護策がない場合、不正アクセスにつながる可能性があります。さらに、単一の認証 (Authentication) ポイントに依存することは、IdP が侵害されるとすべての接続されたアプリケーションが危険にさらされるため、セキュリティ侵害のリスクを高めます。

したがって、ユーザーがサービスへのアクセスを明示的に要求することを保証する、より安全で制御された認証 (Authentication) フローを提供する SP-initiated SSO を使用することを強くお勧めします。

Logto OIDC アプリケーションと IdP-initiated SSO を接続する

Logto は OpenID Connect (OIDC) プロバイダーとして IdP-initiated SSO をサポートしていません。ただし、Logto を SP として構成し、SAML を使用してエンタープライズ IdP と IdP-initiated SSO をサポートすることができます。このセットアップにより、Logto の認証 (Authentication) 機能を活用しながら、IdP の認証 (Authentication) フローの制御を維持できます。

注記:

デフォルトでは、この機能は Logto で有効になっていません。テナントに対して IdP-initiated SSO を有効にする必要がある場合は、サポートチーム にお問い合わせください。

前提条件

IdP-initiated SSO を構成する前に、まず SAML コネクターを作成する必要があります。Console > Enterprise SSO に移動し、IdP と SAML コネクターを設定するためのステップバイステップガイドに従ってください。

SAML コネクターが設定されたら、サインイン体験 セクションで SSO サインイン方法を有効にし、構成が正しいことを確認するために SP-initiated SSO フローをテストします。IdP-initiated SSO に進む前に、SP-initiated SSO が期待どおりに動作していることを確認してください。

IdP-initiated SSO を有効にする

テナントに対して IdP-initiated SSO 機能が有効になると、SAML コネクターの設定ページに IdP-initiated SSO という追加のタブが表示されます。コネクターの機能を有効にするには、IdP-initiated SSO トグルをオンにします。

SP アプリケーションを選択する

SP-initiated SSO とは異なり、認証 (Authentication) フローが SP から始まるのではなく、IdP-initiated SSO では認証 (Authentication) プロセス後にユーザーをリダイレクトするクライアント側の SP アプリケーションが必要です。Default application ドロップダウンから登録済みアプリケーションのリストから SP アプリケーションを選択できます。

IdP-initiated SSO では、Traditional Web AppSingle Page App アプリケーションのみがサポートされています。使用ケースに基づいて適切なアプリケーションタイプを選択してください。

注記:

IdP 側では、IdP-initiated SSO フローが正しく機能するように RelayState パラメーターを EMPTY にしておいてください。Logto は選択されたデフォルトの SP アプリケーションに基づいてリダイレクトを処理します。

IdP-initiated 認証 (Authentication) フローを構成する

IdP-initiated SAML SSO を OIDC と接続するために、Logto は認証 (Authentication) リクエストを処理するための 2 つの構成オプションを提供します。

IdP が SSO フローを開始し、SAML アサーションを Logto に送信すると、IdP-initiated SSO アサーションセッションが作成されます。Logto はユーザーをデフォルトの SP アプリケーションにリダイレクトし、クライアント側で標準の OIDC 認証 (Authentication) リクエストを開始します。

このオプションを設定するには、SAML コネクター設定の IdP-initiated SSO タブで Redirect to client for SP-initiated authentication カードを選択します。

SP-initiated SSO フロー

  1. IdP-initiated SSO フロー後にユーザーをデフォルトの SP アプリケーションにリダイレクトするための Client redirect URL を提供します。Logto はこの URL に ?ssoConnectorId={connectorId} クエリパラメーターを追加してユーザーをリダイレクトします。クライアントアプリケーションはリダイレクトを処理し、OIDC 認証 (Authentication) リクエストを開始する必要があります。(IdP-initiated SSO 認証 (Authentication) リクエストを処理するために、クライアントアプリケーションに専用のルートまたはページを使用することをお勧めします。)

  2. クライアント側で ssoConnectorId クエリパラメーターを使用して、IdP-initiated SSO 認証 (Authentication) フローを開始した SAML コネクターを識別し、OIDC 認証 (Authentication) リクエストを処理します。

  3. サインインリクエストで direct sign-in 認証 (Authentication) パラメーターを Logto に渡して SSO 認証 (Authentication) フローを完了します。

// React の例
import { Prompt, useLogto } from '@logto/react';
import { useEffect } from 'react';
import { useNavigate, useSearchParams } from 'react-router-dom';

const SsoDirectSignIn = () => {
const { signIn } = useLogto();
const [searchParams] = useSearchParams();

useEffect(() => {
const ssoConnectorId = searchParams.get('ssoConnectorId');
if (ssoConnectorId) {
void signIn({
redirectUri,
prompt: Prompt.Login,
directSignIn: {
method: 'sso',
target: ssoConnectorId,
},
});
}
}, [searchParams, signIn]);
};
  • redirectUri: OIDC 認証 (Authentication) フローが完了した後にユーザーをリダイレクトする redirect_uri
  • prompt=login: IdP-initiated SSO アイデンティティを使用してユーザーにログインを強制します。
  • directSignIn=sso:{connectorId}: 直接サインイン方法を sso として指定し、ターゲット SAML コネクター ID を指定します。このパラメーターは、ログインページを表示せずに SSO 認証 (Authentication) フローを直接トリガーします。コネクター ID が一致し、セッションが有効であれば、保存された IdP-initiated SSO アサーションセッションを使用してユーザーが自動的に認証 (Authentication) されます。

この方法は、認証 (Authentication) フローが安全で標準の OIDC プロトコルに従いながら、IdP の認証 (Authentication) プロセスの制御を維持することを保証します。クライアントアプリは、追加のログインステップなしでユーザーを認証 (Authentication) するために IdP-initiated SSO アサーションセッションを利用できますが、認証 (Authentication) フローを安全かつ制御された状態に保ちます。クライアントアプリは、認証 (Authentication) リクエストが安全であることを確認するために state および PKCE パラメーターを検証することもできます。

注記:

この方法は、Traditional Web AppSingle Page App アプリケーションの両方で利用可能です。そして、すべての使用ケースに推奨されます。

オプション B: IdP-initiated SSO で直接ユーザーを認証 (Authentication) する

特定の状況では、SP が IdP-initiated SSO コールバックを処理し、OIDC 認証 (Authentication) リクエストを開始できない場合があります。この場合、Logto は IdP-initiated SSO アサーションセッションを使用してユーザーを直接認証 (Authentication) するための代替オプションを提供します。

このオプションは安全性が低く、推奨されません。認証 (Authentication) フローは標準の OIDC プロトコルをバイパスします。認証 (Authentication) リクエストが IdP によって開始されるため、クライアントアプリは認証 (Authentication) リクエストを安全に検証できない場合があります。例として、クライアントアプリは認証 (Authentication) リクエストが安全であることを確認するために state および PKCE パラメーターを検証できません。

警告:

この方法は Single Page App アプリケーションでは利用できません。クライアントアプリが PKCE パラメーターを使用して認証 (Authentication) リクエストを安全に処理する必要があるためです。SPA アプリケーションに対して IdP-initiated SSO を実装する必要がある場合は、上記のオプションを使用してください。

このオプションを構成するには、SAML コネクター設定の IdP-initiated SSO タブで Directly sign-in using IdP-initiated SSO オプションを選択します。

IdP-initiated SSO フロー

  1. 認証 (Authentication) が成功した後にユーザーをクライアントアプリケーションに戻すための Post sign-in redirect URI を選択します。この URL は OIDC 認証 (Authentication) リクエストの redirect_uri として使用されます。URI はクライアントアプリケーションに登録された許可されたリダイレクト URI の 1 つでなければなりません。

    注記:

    IdP-initiated SSO には専用の redirect URI を使用することを強くお勧めします。認証 (Authentication) リクエストが未承諾であるため、クライアントアプリケーションは標準の SP-initiated 認証 (Authentication) フローとは別にレスポンスを独立して管理する必要があります。

  2. 必要に応じて Additional authentication parameters JSON エディターを使用して認証 (Authentication) リクエストパラメーターをカスタマイズします(タイプ Map<string,string> に従います)。

    例として、Logto はデフォルトで openidprofile スコープのみを要求します。認証 (Authentication) リクエストに追加のスコープやパラメーターを追加できます。

    {
    "scope": "email offline_access"
    }
    • ユーザーのメールアドレスを要求するために追加の email スコープを追加します。
    • リフレッシュ トークンを要求するために offline_access スコープを追加します。

    認証 (Authentication) レスポンスを安全に検証するためにカスタム state パラメーターを提供することもお勧めします。

    {
    "state": "custom-state-value"
    }

    クライアントアプリは、認証 (Authentication) リクエストが有効であることを確認するために、認可コードレスポンスで state パラメーターを検証する必要があります。