日本語

oauth
セキュリティ
oidc
認証

リソースオーナーパスワードクレデンシャル (ROPC) グラントタイプを非推奨にすべき理由

リソースオーナーパスワードクレデンシャル (ROPC) グラントタイプは、古い OAuth 2.0 フローであり、セキュリティリスクを伴うため、非推奨にすべきです。本記事では、アプリケーションで ROPC を使用することを避ける理由を示します。

Simeng

Developer

4/24/2024

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

はじめに

リソースオーナーパスワードクレデンシャル (ROPC) グラントタイプ、別名パスワードグラントタイプは、アプリケーションがユーザーのユーザー名とパスワードをアクセストークンと交換することを許可する OAuth 2.0 フローです。これは、HTTP ベーシック認証や、より安全な OAuth トークン化されたフローを使用することができなかった古いネイティブアプリケーションなど、レガシーアプリケーションをサポートするために最初に OAuth 2.0 仕様で導入されました。

しかし、ROPC グラントタイプは複数のセキュリティリスクを伴うため、OAuth 2.0 セキュリティベストプラクティスでは使用してはならないとされています。

最近、ROPC グラントタイプの実装に関するガイダンスやサポートを求めるお客様からの質問をいくつか受け取りました。本記事では、特に新しいアプリケーションに対して ROPC グラントタイプの使用を避けるべき理由を説明します。

ROPC グラントタイプ vs. 認可コードフロー

ROPC グラントタイプの動作

ROPC グラントタイプは、ユーザーのユーザー名とパスワードをアクセストークンと交換するシンプルなフローです。クライアントアプリケーションは、ユーザーのクレデンシャルを直接収集し、それを認可サーバーに直接送信します。認可サーバーがクレデンシャルを検証し、クライアントにアクセストークンを発行します。

認可コードフローの動作

対照的に、認可コードフローは Web アプリケーションに推奨される OAuth 2.0 フローです。これは、クライアントアプリケーション、認可サーバー、およびユーザーのブラウザ間で複数のステップとリダイレクトを含みます。認可コードフローは、ユーザーのクレデンシャルをクライアントアプリケーションに公開しないため、より安全です。

ROPC グラントタイプと認可コードフローの主な違いは、ROPC はユーザーのクレデンシャルをクライアントアプリケーションに公開するのに対し、認可コードフローはそうしないことです。ユーザーのクレデンシャルは認可サーバー内で機密性を保つ必要があります。クライアントアプリケーションがユーザーに代わってリソースを要求する場合、ユーザーを認可サーバーにリダイレクトしてクライアントアプリケーションを認証および認可させるべきです。これにより、クライアントアプリケーション側での認可データの保有が最小限に抑えられます。

ROPC グラントタイプのセキュリティリスク

1. ユーザークレデンシャルの露出

前述のように、ROPC グラントタイプはユーザーのクレデンシャルをクライアントアプリケーションに公開します。これは重大なセキュリティリスクであり、クライアントアプリケーションがユーザーのクレデンシャルを保存またはログに記録し、ユーザーの認識なしに再承認を得ることができるためです。

特にモバイルアプリケーションやシングルページアプリケーションのような公開クライアントアプリケーションの場合、クライアントアプリケーションは容易に注入されたりリバースエンジニアリングされたりして、ユーザーのクレデンシャルを抽出される可能性があります。モバイルアプリケーションやウェブブラウザで動作するシングルページアプリケーションのどちらも、機密情報を保持できるわけではないため、ユーザーのクレデンシャルを公開せずにユーザーを認証することはできません。

たとえリソースオーナーがクライアントアプリケーションと信頼関係を持っていても、クライアントアプリケーションは認証プロセス全体で中間者攻撃の役割を果たし、他の悪意のあるアクターによって侵害される可能性があります。悪意のあるアクターはユーザーのクレデンシャルを盗み、ユーザーになりすましてユーザーのリソースにアクセスすることができます。

クライアントアプリケーションのセキュリティ態勢に基づいて、ユーザーのクレデンシャルを盗むにはいくつかの方法があり、キーロガー、フィッシング攻撃、マルウェアなどが含まれます。さらに、クライアントのクレデンシャルはすべての認可リクエストでネットワーク上で伝達されるため、クレデンシャルの傍受リスクがさらに高まります。

複数のアプリケーションが ROPC グラントタイプを使用している場合、クレデンシャルの露出リスクが倍増する可能性があります。

2. ROPC はユーザーの同意をサポートしません

ROPC グラントタイプはユーザーの同意をサポートしません。クライアントアプリケーションがユーザーのクレデンシャルを直接収集すると、ユーザーはクライアントアプリケーションが自分のリソースにアクセスすることを確認および承認する機会がありません。これはユーザーのプライバシーと信頼を損なうことになります。

ユーザーは、どのクライアントアプリケーションが自分のリソースにどれくらいの期間アクセスできるかを決定する権利を持つべきです。特にサードパーティアプリケーションに対しては、ユーザーの同意メカニズムがリソースオーナーのデータを保護するために不可欠であり、GDPR などのデータ保護規則に準拠するためにも重要です。

3. ROPC は多要素認証をサポートしません

多要素認証 (MFA) は、ユーザーがリソースにアクセスするために 2 つ以上の確認要素を提供することを要求するセキュリティ実装です。これにより、認証プロセスに追加のセキュリティ層が加わります。ROPC グラントタイプは MFA をサポートしていません。代わりに認証プロセスを単一の要素に制限し、トークンリクエストはユーザーのクレデンシャルのみに基づいています。すなわち、SMS OTP、Eメール OTP、または WebAuthn のような挑戦ベースの認証メカニズムを ROPC グラントタイプで実装することは不可能です。

ROPC はモダンなアプリケーションには対応していません

ROPC グラントタイプは、シングルサインオン (SSO) などのモダンなアイデンティティおよびアクセス管理 (IAM) システムをサポートできない旧式のアプリケーションをサポートするために設計されました。

1. ROPC は SSO に対応していません

シングルサインオン (SSO) は、モダンな認証アーキテクチャで、一度のログインで複数のアプリケーションにシームレスにアクセスできるようにします。

集中型 IdP は、SSO アーキテクチャにおいて重要な役割を果たします。これにより、ユーザーの認証セッションが管理され、クライアントアプリケーションにトークンが発行されます。クライアントアプリケーションは、ユーザーのクレデンシャルを直接収集する必要がなく、ユーザーのクレデンシャルは IdP 内で機密性を保ちます。

ROPC グラントタイプは SSO をサポートしていません。これは、クライアントアプリケーションがユーザーのクレデンシャルを直接収集する必要があり、SSO アーキテクチャを破壊します。これは、OpenID Connect (OIDC) や SAML のようなモダンな SSO システムとは互換性がありません。

2. ROPC はフェデレーティッドアイデンティティに対応していません

SSO アーキテクチャと同様に、フェデレーティッドアイデンティティにより、ユーザーは既存のアイデンティティを使用して複数のサードパーティアプリケーションにアクセスできます。ユーザーは、Google、Facebook、Twitter などの複数のソーシャルアカウントを集中型 IdP にリンク付けし、これらのソーシャルアカウントを使用してクライアントアプリケーションに認証します。すべてのフェデレーティッドアイデンティティは IdP によって管理されており、クライアントアプリケーションはユーザーの認証の詳細を知ることはありません。

ROPC グラントタイプは、代わりにクライアントアプリケーションがユーザーのクレデンシャルを直接収集することを要求します。これによりクライアントアプリケーションのフェデレーティッドアイデンティティのサポートが制限され、ユーザーのアイデンティティデータがクライアントアプリケーションに公開されることになります。

結論

リソースオーナーパスワードクレデンシャル (ROPC) グラントタイプは、重大なセキュリティリスクを伴うレガシー OAuth 2.0 フローであり、非推奨にすべきです。これは、ユーザーのクレデンシャルをクライアントアプリケーションに公開し、多要素認証や SSO といったモダンなセキュリティメカニズムをサポートしていません。アプリケーションに ROPC グラントタイプを使用することは避けるよう強く推奨します。ROPC グラントタイプに依存するレガシー認証システムをお持ちであれば、認可コードフローやクライアントクレデンシャルフローなど、より安全な OAuth 2.0 フローへの移行を検討してください。

アプリケーションに安全なユーザー認証および認可サービスを統合する、またはレガシーパスワードベースの認証システムからより安全な OAuth 2.0 フローへの移行を支援するために支援が必要な場合は、こちらからご連絡ください。安全でモダンなアプリケーションの構築をサポートさせていただきます。

はじめに#

ROPC グラントタイプ vs. 認可コードフロー#

ROPC グラントタイプの動作#

認可コードフローの動作#

ROPC グラントタイプのセキュリティリスク#

1. ユーザークレデンシャルの露出#

2. ROPC はユーザーの同意をサポートしません#

3. ROPC は多要素認証をサポートしません#

ROPC はモダンなアプリケーションには対応していません#

1. ROPC は SSO に対応していません#

2. ROPC はフェデレーティッドアイデンティティに対応していません#

結論#

はじめに#

ROPC グラントタイプ vs. 認可コードフロー#

ROPC グラントタイプの動作#

認可コードフローの動作#

ROPC グラントタイプのセキュリティリスク#

1. ユーザークレデンシャルの露出#

2. ROPC はユーザーの同意をサポートしません#

3. ROPC は多要素認証をサポートしません#

ROPC はモダンなアプリケーションには対応していません#

1. ROPC は SSO に対応していません#

2. ROPC はフェデレーティッドアイデンティティに対応していません#

結論#

はじめに

ROPC グラントタイプ vs. 認可コードフロー

ROPC グラントタイプの動作

認可コードフローの動作

ROPC グラントタイプのセキュリティリスク

1. ユーザークレデンシャルの露出

2. ROPC はユーザーの同意をサポートしません

3. ROPC は多要素認証をサポートしません

ROPC はモダンなアプリケーションには対応していません

1. ROPC は SSO に対応していません

2. ROPC はフェデレーティッドアイデンティティに対応していません

結論

はじめに

ROPC グラントタイプ vs. 認可コードフロー

ROPC グラントタイプの動作

認可コードフローの動作

ROPC グラントタイプのセキュリティリスク

1. ユーザークレデンシャルの露出

2. ROPC はユーザーの同意をサポートしません

3. ROPC は多要素認証をサポートしません

ROPC はモダンなアプリケーションには対応していません

1. ROPC は SSO に対応していません

2. ROPC はフェデレーティッドアイデンティティに対応していません

結論