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

OIDC 認証 (Authentication) フローを理解する

Logto は OAuth 2.0 および OpenID Connect (OIDC) 標準に基づいて構築されています。これらの認証 (Authentication) 標準を理解することで、統合プロセスがよりスムーズかつ簡単になります。

ユーザー認証 (Authentication) フロー​

ユーザーが Logto でサインインする際の流れは次の通りです：

このフローでは、統合プロセスにおいていくつかの重要な概念があります：

  • Application：これは Logto 上でのアプリケーションを指します。Logto コンソールでアプリケーション設定を作成し、実際のアプリケーションと Logto サービス間の接続を確立します。詳細は Application を参照してください。
  • Redirect URI：ユーザーが Logto サインインページで認証 (Authentication) を完了した後、この URI を通じて Logto からアプリケーションへリダイレクトされます。アプリケーション設定で Redirect URI を設定する必要があります。詳細は Redirect URIs を参照してください。
  • サインインコールバックの処理：Logto からユーザーがアプリケーションへリダイレクトされた際、アプリケーションは認証 (Authentication) データを処理し、アクセス トークン (Access token) とユーザー情報をリクエストする必要があります。ご安心ください ― Logto SDK が自動的に処理します。

この概要で素早く統合するための要点をカバーしています。さらに詳しく知りたい場合は、サインイン体験の解説 ガイドをご覧ください。

マシン間通信 (M2M) 認証 (Authentication) フロー​

Logto は マシン間通信 (M2M) アプリケーション タイプを提供し、OAuth 2.0 クライアントクレデンシャルフロー に基づいてサービス間の直接認証 (Authentication) を可能にします：

このマシン間通信 (M2M) 認証 (Authentication) フローは、ユーザー操作なし（UI なし）でリソースと直接通信する必要があるアプリケーション向けに設計されています。例えば、Logto 上のユーザーデータを更新する API サービスや、日次注文データを取得する統計サービスなどです。

このフローでは、サービスはクライアントクレデンシャル（Application ID と Application Secret の組み合わせ）を使って認証 (Authentication) します。これらのクレデンシャルは、Logto から アクセス トークン (Access token) をリクエストする際のサービスのアイデンティティとなります。

デバイスフロー（入力制限デバイス向け）​

入力機能が制限されたデバイス（例：スマート TV、ゲーム機、CLI ツール、IoT デバイス）向けに、Logto は OAuth 2.0 デバイス認可グラント をサポートしています。デバイスはコードと URL を表示し、ユーザーは別のデバイス（ブラウザ）で認証 (Authentication) を完了します：

このフローでは：

  • デバイスが Logto からデバイスコードをリクエストし、短い user_code と verification_uri を受け取ります。
  • ユーザーは別のデバイス（スマートフォンやノート PC など）で認証用 URL にアクセスし、コードを入力してサインインします。
  • デバイスはユーザーが認可を完了するまでトークンエンドポイントをポーリングし、完了後にトークンを受け取ります。

標準のユーザーフローと異なり、デバイスフローではデバイス自体にリダイレクト URI やブラウザ機能は不要です。詳細は デバイスフロー クイックスタート をご覧ください。

SAML 認証 (Authentication) フロー​

OAuth 2.0 や OIDC に加え、Logto は SAML（Security Assertion Markup Language）認証 (Authentication) もサポートしており、アイデンティティプロバイダー (IdP) としてエンタープライズアプリケーションとの統合を可能にします。現在、Logto は SP-initiated 認証 (Authentication) フローをサポートしています：

SP-initiated フロー​

SP-initiated フローでは、認証 (Authentication) プロセスはサービスプロバイダー（アプリケーション）から開始されます：

このフローでは：

  • ユーザーがアプリケーション（サービスプロバイダー）から認証 (Authentication) を開始します
  • アプリケーションが SAML リクエストを生成し、ユーザーを Logto（アイデンティティプロバイダー）へリダイレクトします
  • Logto で認証 (Authentication) が成功すると、SAML レスポンスがアプリケーションへ返されます
  • アプリケーションが SAML レスポンスを処理し、認証 (Authentication) を完了します

IdP-initiated フロー​

Logto は今後のリリースで IdP-initiated フローもサポート予定です。これにより、ユーザーは Logto のポータルから直接認証 (Authentication) プロセスを開始できるようになります。今後のアップデートにご期待ください。

この SAML 統合により、エンタープライズアプリケーションは Logto をアイデンティティプロバイダーとして活用でき、最新およびレガシーな SAML ベースのサービスプロバイダーの両方をサポートします。

ブログ：OAuth 2.0 と OpenID Connect でクラウドアプリケーションを安全に

複数アプリケーション向けシングルサインオン (SSO) の利点

複数アプリビジネスにおける中央集権型アイデンティティシステムの必要性