日本語

oauth
暗黙的フロー
承認コード
PKCE

暗黙的フロー vs. 承認コードフロー: なぜ暗黙的フローは終わったのか？

OAuth 2.0 に「承認コードフロー」があるのはなぜでしょう？すでに「暗黙的フロー」が存在するにもかかわらず...。これら 2 つの認可タイプの詳細を調べ、なぜ暗黙的フローの使用を避けるべきかを見つけましょう。

Darcy Ye

Developer

1/3/2024

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

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

始めましょう

承認コードフローと暗黙的フローは、OAuth 2.0 で最も一般的に使用される認可タイプの 2 つであり、Web アプリケーションの安全で効率的なユーザー認可を可能にします。両方のフローは、ユーザーが資格情報を直接公開することなくアプリケーションにアクセスを許可するための承認プロセスを実装しています。暗黙的フローは、ブラウザの制限に対処するために最初に開発されましたが、現代の Web テクノロジーの出現により、承認コードフローが多くの開発者にとって好まれる選択肢となり、その強化されたセキュリティ機能が理由です。

この記事では、これら 2 つの承認タイプの違いを探索し、暗黙的フローの代わりに承認コードフローを使用すべき理由を説明します。

OAuth 2.0 とは？

これら 2 つの承認タイプの詳細に入る前に、まず OAuth 2.0 が何であるか、そして現代の Web アプリケーションでなぜ重要であるのかを理解しましょう。

OAuth に関して人々が話すとき、通常、OAuth 2.0 のことを指します。これは「オープン認可」として知られ、Web サービスがユーザーの代わりにリソースを活用できるようにする確立されたプロトコルです。Oauth 1.0 の後継として 2012 年に登場し、それ以来デジタル認可の広く受け入れられた標準になりました。OAuth 2.0 は、ユーザーのログイン情報を明らかにすることなく、クライアントアプリケーションがユーザーのリソースを操作する特定の許可を与えるための仕組みを提供するよう設計されています。

主に Web 環境で利用されますが、OAuth 2.0 のフレームワークはさまざまなクライアント形式にも拡張されています。これにはブラウザベースのアプリケーション、サーバ側 Web アプリケーション、ネイティブまたはモバイルアプリケーション、さらには相互接続されたデバイスも含まれ、これらのプラットフォーム間で委任されたアクセスを管理する方法が詳述されています。これは「認可タイプ」の概念を導入し、クライアントアプリケーション、ユーザー、承認サーバ間の承認プロセスを定義します。これらの認可タイプは、クライアントアプリケーションがユーザーのリソースにアクセスするためのアクセストークンを取得する方法を決定するために使用されます。OAuth 2.0 で最も一般的な認可タイプは次の通りです:

承認コード：あらゆるタイプのアプリケーションに最適であり、特にサーバ側 Web アプリケーションで、クライアントアプリケーションがアクセスコードをアクセストークンに交換してトークンを安全に管理できます。
暗黙的：簡略化されたフローで、安全なサーバコンポーネントなしでブラウザベースのアプリケーション向けに設計されています。クライアントアプリケーションへの迅速なトークン配信を目的に作成されましたが、現在はセキュリティ上の懸念から大幅に非推奨とされています。
リソースオーナーパスワード資格情報：このタイプではクライアントアプリケーションがユーザーの資格情報（ユーザー名とパスワード）を直接送信してアクセストークンをリクエストおよび受信することが許可されます。クライアントアプリケーションがユーザーの資格情報に直接アクセスできるため、この認可タイプも非推奨とされ、あらゆる状況で避けるべきです。
クライアント資格情報：アプリケーション自体がクライアントとなるマシンツーマシン通信で使用されます。アプリケーションが認証サーバに認証し、独自のリソースまたは他のサービスのリソースにアクセスするためのアクセストークンを要求することを含みます。

暗黙的フローとは？

暗黙的フローは、追加のステップでアクセスコードをトークンに交換することなく、リダイレクト URI で直接クライアントにアクセストークンを返す簡略化された OAuth 2.0 フローです。ブラウザの制限によってトークンエンドポイントへのサーバ側リクエストを行うことができなかった Web アプリケーション向けに当初設計されました。

暗黙的フローの仕組み

クライアントアプリケーションのボタンやリンクをクリックし、認証プロセスを開始します。
クライアントアプリケーションは、承認サーバにユーザーをリダイレクトして認証し、望ましいアクセス範囲を含めます。
承認サーバは、ユーザーにログインしてクライアントアプリケーションに許可を与えるよう促します。
認証と承認が成功すると、承認サーバはリダイレクト URI でアクセスコードを URL フラグメントに含んでユーザーのブラウザをクライアントにリダイレクトします。
クライアントアプリケーションは URL フラグメントからアクセストークンを抽出し、リソースサーバでユーザーのリソースにアクセスするために使用します。

暗黙的フローのセキュリティリスク

暗黙的フローにはいくつかのセキュリティの脆弱性があります：

トークンの露出: アクセストークンが URL フラグメントに直接返されるため、悪意のある当事者によって簡単に傍受される可能性があります。これにより、アクセストークンが盗難や不正使用のリスクにさらされます。
CSRF 攻撃: 暗黙的フローは、悪意のあるウェブサイトがユーザーに対してアカウントへの不正なアクセスを許可させるクロスサイトリクエストフォージェリ (CSRF) 攻撃を受けやすくなります。

これらのセキュリティ上の懸念から、暗黙的フローは現代の Web アプリケーションにはもはや推奨されません。代わりに、PKCE（コード交換のための証明キー）を備えた承認コードフローが安全なユーザー認証のための好ましい選択肢です。

承認コードフローとは？

一方で、承認コードフローは、クライアントアプリケーションがまず承認サーバから承認コードを取得し、その後トークンを取得する手順を踏む、よりセキュアな OAuth 2.0 フローです。このフローは、クライアント資格情報を安全に保存しアクセストークンを管理できるサーバ側 Web アプリケーション向けに設計されました。PKCE 拡張機能の導入により、ブラウザベースのアプリケーションでも承認コードフローが使用できるようになりました。

サーバ側コンポーネントを持つプライベートクライアント用の承認コードフローの仕組み

クライアントアプリケーションのボタンやリンクをクリックし、認証プロセスを開始します。
クライアントアプリケーションは、望ましいアクセスの範囲を持って承認サーバにユーザーをリダイレクトします。
承認サーバは、ユーザーにログインしてクライアントアプリケーションに許可を与えるよう促します。
認証と承認が成功すると、承認サーバはクライアントに承認コードを返します。
クライアントアプリケーションは、クライアント資格情報を使用してトークンエンドポイントにサーバ間リクエストを行い、承認コードをアクセストークンに安全に交換します。
承認サーバは、承認コードとクライアント資格情報を検証し、クライアントにアクセストークンを返します。
クライアントアプリケーションは、アクセストークンを使用してリソースサーバでユーザーのリソースにアクセスします。

PKCE と公共クライアント用の承認コードフローの仕組み

クライアントアプリケーションのボタンやリンクをクリックし、認証プロセスを開始します。
クライアントアプリケーションは、コード検証器とコードチャレンジを生成します。
クライアントアプリケーションは、コードチャレンジを持って承認サーバにユーザーをリダイレクトして認証します。
承認サーバが後で検証のためにコードチャレンジを保存します。
ユーザーが認証し、クライアントアプリケーションにアクセスを許可します。
承認サーバがクライアントに承認コードを返します。
クライアントアプリケーションはコード検証器を使ってトークンエンドポイントにサーバ間リクエストを行い、承認コードをアクセストークンに交換します。
承認サーバが承認コードとコード検証器を保存されたコードチャレンジに対して検証します。
承認サーバがクライアントにアクセストークンを返します。
クライアントアプリケーションがアクセストークンを使用してリソースサーバでユーザーのリソースにアクセスします。

詳細を学ぶには、PKCE フローをご覧ください。