本記事は元々 blog.logto.io に掲載されたものです。
初めから、Logtoはオープンスタンダードへの強い信念を持って構築されました。私たちは、OIDC、OAuth 2.0、SAMLのようなプロトコルに従うことを選びました。これらは広く使用されているだけでなく、業界全体で信頼されている確立された安全な実践を表すからです。セキュリティは常に私たちの優先事項でした。また、オープンソースの精神に忠実であること、Customer Identity Managementと現代の認証におけるベストプラクティスに従うこともそうです。
しかし、私たちは道中でもいくつかのことを学びました:
OAuth 2.0とOIDCは誰にとっても簡単ではありません。これらのプロトコルに不慣れな開発者にとって、その概念は外国的で時には直感に反するように感じられます。これが、セキュリティを損なうことなく開発者の体験を簡素化する方法を模索する際の実際の課題に繋がりました。
2つのことが特に目立ちました:
- インテグレーションを可能な限りスムーズにするために努力したのですが、IDトークン、アクセストークンの基本的な概念の理解に関してまだ学習曲線があります。
- よくある質問は：「ログイン画面でリダイレクトをスキップできますか？」です。残念ながら、リダイレクションはOIDCが機能する重要な部分であり、安全な認証のために必要です。
Discordユーザーからのよくある質問（プライバシーのためにIDとアバターがぼかされています）。
すべての決定にはトレードオフがありますが、時には最初に下した選択が、新しいユースケースが出現するにつれて特に価値のあるものになることがあります。そして今、私たちは新しい時代、AIの時代に突入しています。
この記事では、あなたの製品がOIDCとOAuth 2.0を使用すべき場合、そうでない場合、そして本物のビジネスを構築し、CIAMソリューションを選択するなら、これらのオープンスタンダードを初めから採用することを私が常に推奨してきた理由を探ります。AIの台頭がなぜこの決定をこれまで以上に重要にしているのかも説明します。
OAuth 2.0が実際に何をするのか（簡単なたとえ話と共に）
OAuth 2.0にあまり詳しくない読者のために、一瞬だけ基本的な概念を再び簡単に振り返ってみましょう。もっと明確にするためです。
OAuth 2.0は委任された認可のためのものです：OAuth 2.0は認可のための業界標準プロトコルであり、リソース所有者の同意を得て、一つのサービスが別のサービスのリソースにアクセスすることを可能にします。
OAuthのシナリオでは、ユーザー（リソース所有者）はクライアントアプリケーションに限定的なアクセス（スコープされた権限）をAPIやリソースサーバーに与えます。OAuthは、クライアントが保護されたAPIを呼び出すのに使用できるアクセストークンをリクエストし発行する方法を定義しています。これはアプリが他のサービスにアクセスするために資格情報を尋ねるかもしれない初期の時代と比較して画期的でした（深刻なセキュリティリスク）。OAuth 2.0では、ユーザーが特定のアクセスを承認し、クライアントが必要な許可と期間のみを持つトークンを取得します - パスワードは交換されず、セキュリティが大幅に向上します。
OAuth 2.0はホテルにチェックインするようなものだと考えてください。
あなた（ユーザー）は部屋の所有者（あなたのデータ）です。しかし、誰かにあなたの部屋の鍵（あなたのパスワード）を与える代わりに、フロントに行き、一時的なアクセスカード（アクセストークン）を要求します。それはジムやプールに入るためだけにあなたのゲストや友人に機能します - 部屋全体には機能しません。
ホテルのスタッフ（OAuthシステム）は次の特定のルールを持つこの限定カードを発行します:
- それはジム（特定のリソース）でのみ機能します。
- 有効期限は短いです。
- 誰もあなたの部屋に入ることはできません。
この方法では、メインの鍵を与える必要がなく、システムはその限定カードを誰かが手に入れたとしても安全を保ちます。
別の例を見てみましょう。OAuth 2.0はソーシャルサインインのシナリオで広く使用されています。
たとえば、Notionのような新しいアプリにサインアップするときに、新しいユーザー名とパスワードを作成する代わりに、「Googleで続ける」をクリックすることにしましょう。
ここでOAuth 2.0で舞台裏で起こること:
-
あなたはGoogleのログインページにリダイレクトされ、そこにログインします（まだログインしていない場合）。
-
Googleは尋ねます:
“このアプリにあなたの基本的なプロフィールとメールアドレスを表示することを許可しますか？”
-
あなたが「許可」をクリックすると、Googleはアプリにアクセストークンを送ります。
-
アプリはそのトークンを使用して:
- あなたの身元（メールとプロフィール情報を通じて）を確認します。
- あなたのアカウントを作成またはログインします — Googleのパスワードを見ることなく。
OIDCが実際に何をするのか（簡単なたとえ話と共に）
次に、OIDC — より新しく、より高度な標準を見てみましょう。OpenID Connectはアイデンティティと認証を目指します：それはOAuth 2.0の上に構築された認証レイヤーです。OAuth 2.0は単独ではアプリケーションにユーザーが誰かを伝えません（アクセストークンとスコープに関するものだけです）。OIDCはユーザーのログインとアイデンティティを処理する標準的な方法を追加します。
OIDCを使用する場合、認証サーバーはユーザーを認証し、ユーザーに関する情報（「アイデンティティクレーム」）を含むIDトークンを発行するOpenIDプロバイダー（アイデンティティプロバイダー）としても機能します。
簡単に言えば、OAuth 2.0は*「このクライアントはこのリソースにアクセスできますか？」に答え、OIDCは「今ログインしたユーザーは誰か？」*に答えます。これにより、アプリはユーザーのIDを確認し、その後ユーザーの代理としてAPIにアクセスするための認証済みトークンを使用できます。
OAuth 2.0とOIDCをホテルのたとえで再度理解しましょう。
ホテルにチェックインしていると想像してください。
-
OAuth 2.0は、ホテルがあなたの友人に代わってジムとプールを使わせるように頼むようなものです。
あなたはフロントに行き、許可を与え、ホテルはあなたの友人にゲストパスを与えます。
ホテルは友人が誰かには興味がありません—ただ彼らが施設を使うことが許可されていることだけ。
👉 それがOAuthです：「このアプリは私のデータやサービスの一部にアクセスできます。」
-
OIDCは、彼らをアクセスさせる前にホテルがその人が誰かを確認するように頼むようなものです。
あなたの友人も身分証明書を見せ、ホテルは彼らの名前、ステータス、そして彼らが認証されたゲストであることを知ります。
👉 それがOIDCです：「ユーザーが誰であるか、彼らがサインインしました。」
OIDCはOAuth 2.0を延長してユーザー認証とアイデンティティデータを追加しますが、そのコアとなる認可フレームワークと完全に互換性があります。
LogtoがOAuth 2.0とOpenID Connect (OIDC)をどのように使用するか
Logtoのコア認証機能はOIDC (OpenID Connect)の上に構築されています
Logtoのコアは、OAuth 2.0の上に構築された標準であるOpenID Connect (OIDC)プロバイダーです。LogtoはプロフェッショナルなCIAMソリューションであり、アイデンティティは私たちが管理するコアビルディングブロックです。
私たちはセキュリティを基にしてLogtoを設計しました。それはPKCEをデフォルトで強制し、暗黙のフローのような安全でないフローをブロックし、リダイレクションに頼って安全にサインインを処理します。
なぜリダイレクションが必要なのか？
OIDCはブラウザベースの認証のためのものです。それは単なる技術的な選択ではありません — 異なるプラットフォーム間でユーザーに安全で一貫した体験を提供するためのものです。Logto、Google、またはMicrosoftのようなアイデンティティプロバイダーにユーザーをリダイレクトすることで、それを実現可能にします。
これが通常のフローのようになります：
-
ユーザーが「サインイン」をクリック
→ あなたのアプリは彼らをLogtoのログインページに送ります。
-
彼らは安全にログイン
→ ここでMFA、生体認証、ソーシャルサインインなどが行われます。
-
Logtoが彼らを送り返す
→ 安全なトークンまたは認可コードと共に。
-
あなたのアプリがログインを完了
→ トークンが検証され、ユーザーはサインインします。
このパターンはシンプルに見えるかもしれませんが、強力な利益をもたらします：
- あなたのアプリは直接資格情報を処理しません — それはリスクを減らすことを意味します。
- アプリのコードを変更せずにMFAのような機能を追加するのが簡単になります。
- モバイルにも最適です：
- iOSはASWebAuthenticationSessionを使用します。
- AndroidはCustom Tabsを使用します。
そして、あなたの製品が複数のアプリにまたがる場合、リダイレクションはシングルサインオンを可能にし、ユーザーは一度サインインすればスムーズにアプリ間を移動できます。
Logtoはアプリ内で直接パスワードを収集することをサポートしていません。それは意図されたものです。ROPCフローはOAuth 2.0のセキュリティベストプラクティスには推奨されません。これは安全性が低く、スケールしにくいためです。
LogtoはまたOAuth 2.0/OIDCプロバイダー（アイデンティティプロバイダー）でもあります
Logtoは単なる認証サーバー以上のものです — 完全な**OAuth 2.0、OpenID Connect (OIDC)、およびアイデンティティプロバイダー (IdP)**です。それは、ユーザーアイデンティティを安全に管理し、他のアプリケーションが信頼できるトークンを発行することができます。
あなた自身のアプリのログイン体験を強化することに加えて、Logtoはサードパーティアプリケーションとのインテグレーションをサポートし、外部サービスがLogtoをそのアイデンティティソースとして頼ることを可能にします。
それは実際にはどういう意味ですか？
アイデンティティプロバイダー (IdP)として、Logtoはユーザー検証を行い、資格情報を管理し、認証トークンを発行します。一度ユーザーがサインインすると、Logtoは異なるアプリにアクセスすることを可能にします — 他のベンダーのアプリでさえも — もう一度ログインすることなく。それは「Googleでサインイン」や「Microsoftでサインイン」といった概念と同じです。
このコンテキストには2種類のアプリケーションがあります:
- ファーストパーティアプリ: あなたが構築し、完全に制御するアプリで、直接Logtoと統合されています。
- サードパーティアプリ: あなたの組織外のパートナーや開発者によって構築された外部サービス。
Logtoは、既存のLogtoアカウントを使用してこれらのサードパーティアプリにサインインすることをユーザーに可能にします — ちょうど企業ユーザーがGoogle Workspace資格情報でSlackのようなツールにサインインするのと同様に。これにより:
- あなたのエコシステム全体で**シングルサインオン (SSO)**を提供します。
- オープンプラットフォームを構築し、サードパーティ開発者が彼らのアプリに「Logtoでサインイン」を追加できます。
本当にOAuth 2.0とOIDCが必要な場合
- すでにAuth0（または類似のもの）を使用している場合: Auth0はすでにOAuth 2.0とOIDCプロバイダーです。それはユーザーのログイン、トークンの発行、およびAPIまたはアプリとの統合を管理します。
-
M2M認可：サーバー間（クライアント資格情報フロー）
マシン（またはバックエンドサービス）は、ユーザーなしで安全に通信する必要があります。 - デバイスフロー：スマートTV、コンソール、IoTデバイス: TVやプリンターのようなデバイスはユーザーを認証する必要があります。デバイスフローはOIDCの一部です。
- インテグレーションのニーズがある場合: あなたはユーザーを認証するだけでなく、外部アプリ、パートナー、またはエージェントがあなたのプラットフォームと統合し、ユーザーデータに安全にアクセスすることができるエコシステムを作成しています。
AIの時代においてOAuthとOIDCがなぜ重要なのか
AIの時代には、新たな統合とアクセスのニーズが急増しています — 特に自律エージェント、スマートデバイス、およびシステム間通信の領域で。これらの傾向は、OAuth 2.0とOIDCをこれまで以上に重要なものにしています。以下はそのいくつかの例です:
-
リモートMCPサーバー
あなたはリモートMCP（モデルコンテキストプロトコル）サーバーを構築し、サードパーティエージェントにそれに接続してもらいたいと思っています。これらのエージェントは、ユーザーの信頼を損なうことなく、コンテキストを要求し、アクションを実行し、データを交換するために安全なアクセスが必要です。OAuthは安全にアクセスを委任するメカニズムを提供します。
-
製品の統合を開始
あなた自身のビジネスサービスを運営していて — たとえばプロジェクト管理ツールや顧客プラットフォーム — 他の製品やエージェントがそれと統合できるようにしたいと思っています。それはデータを引き出したり、ワークフローをトリガーしたり、あなたの機能を他の環境に埋め込んだりすることを意味するかもしれません。OAuth 2.0/OIDCはユーザーの資格情報を共有することなく、細かく制御されたトークンベースのアクセス制御を可能にします。
-
自分自身のエージェントを構築する
あなたはAIエージェントやアシスタントを作成していて、それが他のアプリやMCPサーバーとやりとりしたいと思っています — 会議をスケジュールしたり、メールを送信したり、更新を投稿したり、データを照会したりします。これらは第三者サービスへの安全で認証されたアクセスを必要とします。OAuth 2.0はあなたのエージェントがユーザーの代理として行動するための認可を取得する方法です。
-
スマートデバイスの台頭
AI翻訳機やスマート会議ノートテイカーのようなハードウェアデバイスは、LLMのおかげでますます機能的になっています。そして、コストが下がり性能が上がるにつれて、これらのデバイスが市場に出ています。これらのデバイスはしばしば、そして限られた入力インターフェースと共に、ユーザーを認証し、クラウドベースのサービスにアクセスする方法を必要とします。そこでOAuthの**デバイス認可フロー**やOIDCベースのアイデンティティ検証が重要になります。
OAuth 2.0/OIDCが必要ない場合
もちろん、OAuth 2.0またはOIDCが必要ない場合もあります — 少なくとも今は。言い換えれば、あなたの現在のユースケースがシンプルまたは完全に自給自足している場合、これらのプロトコルは即時の価値をもたらさないかもしれません。
しかし、あなたの製品が成長するにつれ、またはエコシステムが拡大するにつれ、OAuth 2.0とOIDCの必要性は長期的にますます明らかになることが多いです。
-
シンプルな内部アプリ
アプリが会社内の少人数でしか使用されず、サードパーティサービスと統合する必要がなく、APIを公開する必要がない場合、基本的なユーザー名-パスワード認証システム（例：クッキーセッション）が十分であるかもしれません。
-
ユーザー認証が不要な場合
製品にユーザーアカウントやアイデンティティ対応機能がない場合 — 例えば公共のコンテンツサイトや静的APIキーを持つサーバー間ツール — OIDCは必要ありません。
-
委任されたアクセスが不要な場合
OAuthは他のシステム（例：Google Drive）でユーザーのデータにアプリがアクセスすることをユーザーが認可する必要がある場合に活躍します。サードパーティAPIと統合したり、複数サービスのワークフローを構築する予定がない場合、OAuthは複雑さを追加し、価値がほとんどありません。
-
単一の環境、最小のリスク
セキュリティのニーズよりもシンプルさと速度が重要な場合、初期段階のプロトタイプ、MVP、または内部テストツールではOAuth/OIDCの実装を後回しにすることができます。
つまり、スケーリング、統合の提供、またはAI/エージェント駆動のワークフローを構築する予定がある場合、OIDCとOAuth 2.0は初期段階での賢い投資です。それらは後で時間を節約し、認証とアクセス制御に関する技術的負債を避けます。
適切な認証戦略を選ぶための最終的な考え
初めはOAuth 2.0やOIDCが必要ないかもしれません — それで全く問題ありません。初期段階では、シンプルなソリューションが仕事をこなすことが多いです。しかし、製品が成長し、エージェントやAIが私たちの構築方法にますます統合され、エコシステムがパートナーや第三者に開放されるに連れて、安全で標準化された認証が必需品になります。
後で追いつこうとする代わりに、今基盤を築く価値があります。OAuth 2.0とOIDCを採用することは、今日の問題を解決することだけにとどまりません — 次に来るものに備えることでもあります。