日本語

oauth
oauth2
セキュリティ

OAuth 2.1 が登場: 知っておくべきこと

OAuth 2.1 の仕様が計画されています。OAuth 2.0 と OAuth 2.1 の主な違いと、それらが Logto にどのように採用されたかを探りましょう。

Simeng

Developer

6/12/2024

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

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

始めましょう

はじめに

OAuth 2.0 (RFC 6749) が 2012 年に登場して以来、ウェブとモバイルアプリの世界は大きく変わりました。人々はデスクトップからモバイルデバイスへ移行し、シングルページアプリケーション (SPA) が流行しています。また、多くの新しいフレームワークやウェブ技術も登場してきました。これらの変化に伴い、セキュリティの課題も増しています。最新のウェブ技術に対応するために、Proof Key for Code Exchange (PKCE) のような新しい RFC が継続的にリリースされ、OAuth 2.0 の強化が図られています。現在のセキュリティ要件に合わせたベストプラクティスをまとめることが重要となり、これが OAuth 2.1 登場の理由です。

今後の OAuth 2.1 では、OAuth ワーキンググループはすべてのベストプラクティスとセキュリティに関する推奨事項を 1 つの文書にまとめることを目的としています。Logto では、最新の標準と OAuth のベストプラクティスを常に受け入れています。この記事では、OAuth 2.0 と OAuth 2.1 の主な違いと、それらが Logto にどのように採用されたかを探ります。

認可コードフローを使用するすべての OAuth クライアントに PKCE が必要

OAuth 2.1 の最も重要な変更の 1 つは、Proof Key for Code Exchange (PKCE) が認可コードフローを使用するすべての OAuth クライアントに必要とされることです。PKCE は、認可コードの傍受攻撃を防ぐためのセキュリティ拡張です。特に、クライアントシークレットを安全に保存できないモバイルアプリケーションやシングルページアプリケーション (SPA) に有用です。

OAuth クライアントは、シークレットを安全に保存できるかどうかに基づいて、2 つの異なるタイプに分類できます。

秘密クライアント: これらのクライアントは、サーバーレンダリングされたウェブアプリケーションやウェブサーバーのように、シークレットを安全に保存できます。すべての認可関連の要求はサーバー側から行われ、クライアントシークレットが漏洩するリスクは低いです。
公開クライアント: これらのクライアントは、シークレットを安全に保存することができません。モバイルアプリや SPA が該当します。クライアントシークレットはクライアント側のコードから簡単に抽出され、攻撃者から保護するのは困難です。

公開クライアントにとって、PKCE は必須のセキュリティ対策です。これは、認可コードが認可要求を開始したクライアントによってのみ交換されることを保証します。

PKCE は、ランダムなコード検証器とその検証器に基づいて生成されたコードチャレンジを生成することで機能します。コード検証器は認可サーバーに送信され、コードチャレンジはアクセストークンと認可コードを交換する際にコード検証器を確認するために使用されます。

OAuth 2.1 では、PKCE は抽象度に関係なく、すべての OAuth クライアントが認可コードフローを採用するために必須となります。これは、潜在的な認可コードの傍受攻撃から普遍的に保護するための重要な調整です。

Logto では、公開クライアントと秘密クライアントの両方に対して、PKCE 検証フローが自動でアクティブ化されます。

SPA およびモバイルアプリにおいて、Logto で認可コードフローを保護するために PKCE は必須のセキュリティ対策です。コードチャレンジを含まない認可要求は、Logto の認可サーバーによって即座に拒否されます。

秘密クライアント (従来のウェブアプリケーション) に関しては、従来の互換性を向上させるために、Logto では認可リクエストでコードチャレンジを省略することを許可しています。しかし、公開クライアントの慣行に従って、コードチャレンジを認可要求に組み込んで PKCE を採用することを秘密クライアントに強く推奨します。

リダイレクト URI の厳密な一致

リダイレクト URI (Uniform Resource Identifier) は、認可サーバーが認証および認可プロセスの後にユーザーを再度リダイレクトする特定のエンドポイントまたは URL です。

OAuth フロー中に、クライアントアプリケーションは初期認可要求の一部としてリダイレクト URI を含めます。ユーザーが認証プロセスを完了すると、認可サーバーは認可コードを含む応答を生成し、指定されたリダイレクト URI にユーザーをリダイレクトします。元のリダイレクト URI からのいかなる逸脱も、認可コードまたはトークンの漏洩につながります。

リダイレクト URI の厳密な文字列一致は、OAuth 2.0 Security Best Current Practices のセクション 4.1 で最初に導入されました。このプラクティスは、リダイレクト URI が認可サーバーに登録されたものと完全に一致している必要があるとしています。登録されたリダイレクト URI からのいかなる逸脱もエラー応答を引き起こします。

開発者が複数のサブドメインやパスなどを管理する際に、特にランダムなサブドメインが多数存在する場合に、ワイルドカードマッチングを実装したいというコミュニティからの多数のリクエストを受けました。ワイルドカードマッチングは確かに便利ですが、オープンリダイレクト攻撃などのセキュリティリスクも伴います。リダイレクト URI の検証を欠如させた場合の危険性の実例については、弊社のブログ記事「OAuth のセキュリティ概観」をご参照ください。

OAuth 2.1 の厳格なセキュリティ基準に沿って、Logto ではリダイレクト URI の厳密な文字列一致を使用しています。この決定は、OAuth フローのセキュリティを優先させるものです。ワイルドカードマッチングを利用する代わりに、すべての潜在的なリダイレクト URI を Logto 認可サーバーに登録することを開発者に推奨しています。これにより、リダイレクト URI の徹底した検証が可能になり、潜在的なセキュリティの脆弱性を軽減します。

インプリシットフローは廃止されました

OAuth 2.0 におけるインプリシット認可フローは、アクセス・トークンがユーザーの認証後に直接 URL フラグメント内に返される SPA 向けに設計されました。この方法は、追加のトークン交換ステップを回避し、クライアントが直接トークンを受け取ることができるため、便利でした。

ただし、この利便性には欠点もあります。アクセス・トークンは、ブラウザの履歴やリファラーヘッダーなどを通じて、不正な第三者に露出される可能性があります。そのため、セキュリティ侵害が発生しやすいです。特に、アクセス・トークンが長期間有効である場合、そのリスクは増大します。たとえば、認可リクエストが悪意のある第三者に傍受された場合、URL フラグメントから容易にアクセス・トークンを抽出し、ユーザーになりすますことが可能です。

OAuth 2.0 Security Best Current Practices では、次のように明確に述べられています。

クライアントは、インプリシット認可 (レスポンスタイプ "token") または認可レスポンスでアクセス・トークンを発行する他のレスポンスタイプを使用すべきではありません。

そのため、インプリシットフローは OAuth 2.1 の仕様から公式に削除されました。

Logto においては、SPA とモバイルアプリの唯一サポートされるフローは PKCE を使用した認可コードフローです。認可コードフローは、認可コードを交換することによってさらにセキュアな方法でアクセス・トークンを取得します。

リソースオーナーパスワードクレデンシャル (ROPC) 認可は廃止されました

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

ROPC 認可タイプは、そのセキュリティリスクのために、OAuth 2.0 の仕様では推奨されていません。クライアントアプリケーションにユーザーの資格情報が露出されるため、潜在的なセキュリティ侵害のリスクがあります。クライアントアプリケーションがユーザーの資格情報を保存する可能性があり、クライアントが侵害された場合、ユーザーの資格情報が攻撃者に露出されるリスクもあります。

後に、OAuth 2.0 Security Best Current Practices セクション 2.4 で、ROPC 認可タイプの使用禁止がさらに強調され、使用すべきではないとされています。その結果、ROPC 認可タイプは OAuth 2.1 仕様から削除されました。

ROPC 認可タイプに関連する高いセキュリティリスクのため、Logto ではこれを一度もサポートしていません。レガシーアプリケーションでまだ直接のユーザー認証フローを使用している場合は、認可コードフローやクライアントクレデンシャル認可など、より安全な方法への移行を強くお勧めします。Logto では、これらの安全な OAuth フローをアプリケーションに容易に統合するためのさまざまな SDK とチュートリアルを提供しています。

開発者が最高の製品体験のために自身でサインインインターフェースをデザインまたはホストしたい場合があることは理解しています。Logto では、ブランディング設定やカスタム CSS など、サインインエクスペリエンス (SIE) のカスタマイズオプションを提供しています。さらに、さまざまなプロジェクトが進行中であり、自分の UI を持ち込み、かつ OAuth フローのセキュリティを維持しながら独自のサインインインターフェースを提供するための柔軟性を開発者に提供します。

結論

OAuth 2.1 は、今日のセキュリティの課題に対処しつつ、現代のウェブおよびモバイルアプリのニーズを取り入れた OAuth プロトコルの最新アップグレードです。OAuth ワーキンググループは、最新のセキュリティ基準とベストプラクティスに適合させるために、OAuth 2.1 を更新および改善し続けています。最新のドラフトである OAuth 2.1 11 は、2024 年 5 月にリリースされ、その最終化に向けて大きな進展が見られます。普及が進むにつれて、OAuth 2.1 のベストプラクティスに従い、セキュリティの向上とユーザー体験の改善を図ることを強くお勧めします。

Logto Cloud を無料で試す

はじめに#

認可コードフローを使用するすべての OAuth クライアントに PKCE が必要#

リダイレクト URI の厳密な一致#

インプリシットフローは廃止されました#

リソースオーナーパスワードクレデンシャル (ROPC) 認可は廃止されました#

結論#

はじめに#

認可コードフローを使用するすべての OAuth クライアントに PKCE が必要#

リダイレクト URI の厳密な一致#

インプリシットフローは廃止されました#

リソースオーナーパスワードクレデンシャル (ROPC) 認可は廃止されました#

結論#

はじめに

認可コードフローを使用するすべての OAuth クライアントに PKCE が必要

リダイレクト URI の厳密な一致

インプリシットフローは廃止されました

リソースオーナーパスワードクレデンシャル (ROPC) 認可は廃止されました

結論

はじめに

認可コードフローを使用するすべての OAuth クライアントに PKCE が必要

リダイレクト URI の厳密な一致

インプリシットフローは廃止されました

リソースオーナーパスワードクレデンシャル (ROPC) 認可は廃止されました

結論