認可の未来: OAuth 2.0 が単なる始まりにすぎない理由

承認はアプリケーションセキュリティの重要なコンポーネントであり、認証され、許可されたユーザーのみが保護されたリソースにアクセスできるようにします。 OAuth 2.0 は認可のための業界標準プロトコルとなり、委任されたアクセス制御のフレームワークを提供します。

2012 年に初めて公開された OAuth 2.0 により、アプリケーションはアクセストークンの発行を通じて、リソース所有者に代わってリソースサーバーがホストするリソースにアクセスできるようになります。これにより、ユーザーは資格情報を公開することなく、サードパーティのアプリケーションに別のサービス上のデータへのアクセスを許可できます。

OAuth は Web 全体で広く採用されており、Facebook、Google、Twitter、Microsoft などの多くの主要なプラットフォームの承認を強化しています。しかし、OAuth の使用が急激に増加するにつれて、脆弱性や弱点も発見されました。これらにより、攻撃者はアクセストークンを盗み、有効なユーザーになりすますことができます。

この記事では、OAuth 2.0 の仕組み、一般的な使用例、ベストプラクティス、および脆弱性の概要を説明します。また、OAuth 以外にも、OpenID Connect、相互 TLS、WebAuthn など、セキュリティの強化を目的としたより高度な認可および認証プロトコルにも目を向けます。最後には、OAuth 2.0 とそれを安全に利用する方法をしっかりと理解できるようになります。さらに、OAuth を超えて最新のアプリケーションのアクセス制御をさらに安全にする新しい標準と技術についての洞察が得られます。

OAuth 2.0 の仕組み

OAuth 2.0 は、ユーザーに代わってアプリケーションがサーバーリソースにアクセスするための安全な承認を提供するアクセス委任のオープンスタンダードです。これにより、ユーザーは資格情報を公開することなく、リソースへの限定的なアクセスを許可できます。

OAuth 2.0 では、次の 4 つの主要な承認フローが定義されています。

認可コードの流れ

認証コードフローは、Web アプリケーションなどの機密クライアントに最適です。これには、アクセストークンを交換するための中間認証コードが含まれます。

クライアントアプリケーションは、ログインしてアクセスを承認するためにユーザーを認証サーバーにリダイレクトします。
認可サーバーはユーザーを認証し、認可コードを使用してリダイレクトします。
クライアントは、認証コードをアクセストークンと交換します。
クライアントは、アクセストークンを使用して API 呼び出しを行い、リソースにアクセスできます。

このフローでは、アクセストークンがユーザーのブラウザを通じて直接送信されることがないため、セキュリティが強化されます。

暗黙的なフロー暗黙的フローは、シングルページ Web アプリなどのユーザーエージェントベースのクライアント用に最適化されています。アクセストークンは、認証コードなしで直接返されます。

クライアントアプリケーションは、ログインしてアクセスを承認するためにユーザーを認証サーバーにリダイレクトします。
認可サーバーはユーザーを認証し、URL フラグメント内のアクセストークンを使用してリダイレクトします。
クライアントは、アクセストークンを使用して API 呼び出しを行い、リソースにアクセスできます。

この簡素化されたフローにより、認可サーバーへの余分な往復の必要がなくなりますが、アクセストークンがブラウザーの履歴に公開されるため、安全性は低くなります。

フローの比較

認証コードフローはより安全ですが、往復回数が多くなります。暗黙的フローはよりシンプルで、セキュリティを犠牲にしてユーザーエージェントクライアント向けに最適化されています。

全体として、OAuth 2.0 は、クライアントアプリケーションが標準化された方法でサーバーリソースにアクセスするための安全な委任された承認フレームワークを提供します。ただし、適切に実装されていない場合、脆弱性は依然として存在します。

OAuth 2.0 の長所と短所

長所:

ユーザー認証情報を共有しない委任された承認
さまざまなクライアントタイプに対応した柔軟な認証フロー
主要なプラットフォームとプロバイダー全体で広く採用されています

短所:

複雑さは一般的な実装ミスにつながります
セキュリティのために HTTPS とトークンの機密性に依存します
アクセストークンが適切に保護されていない場合、漏洩する可能性があります
スコープを超えた限定された組み込みユーザーコンテキスト

OAuth 2.0 は安全な認証という重要な問題を解決しますが、より高度なプロトコルが対処しようとしている弱点があります。

OAuth 2.0 の使用例

OAuth 2.0 は、インターネット上のさまざまなアプリケーションやサービスで認証フローを有効にするために一般的に使用されます。最も一般的な使用例と例には次のようなものがあります。

ソーシャルメディアログイン - Facebook、Twitter、Google、GitHub などのサービスはすべて OAuth 2.0 を利用して、ユーザーがプラットフォームの資格情報を使用して「ログイン」できるようにします。これにより、ユーザーは新しいアカウントの作成を省略し、代わりにこれらのサイトが既存のソーシャルプロファイルに接続することを承認できるようになります。
アプリケーション認証 - モバイルアプリケーションとデスクトップアプリケーションでは、多くの場合、REST API へのアクセスを認証するために OAuth が統合されます。たとえば、アプリは OAuth を使用して、クラウドストレージサービス内のユーザーの写真、アドレス帳サービスの連絡先、または API プロバイダーからのその他のデータにアクセスできます。- セキュリティとシングルサインオン - OAuth により、各アプリケーションの資格情報を個別に管理するのではなく、単一の ID プロバイダーを介した集中認証が可能になります。このシングルサインオン (SSO) アプローチは、セキュリティと利便性を向上させるためにエンタープライズ環境で一般的です。
ユーザーアカウント保護 - セキュリティを重視するユーザーの場合、OAuth を使用すると、プライマリ資格情報を共有せずにアプリケーションアクセスを承認できます。これにより、アプリが侵害されたり悪意がある場合にユーザーのアカウントが保護されます。
サービス統合 - OAuth は、認証フローとアクセストークンを通じて、異なるプラットフォーム間のシームレスな統合を可能にします。サービスはユーザーに代わって API を介して相互に直接接続できるため、冗長な認証手順を実行する際の摩擦や煩雑さを回避できます。

要約すると、OAuth 2.0 は、資格情報を公開せずにユーザーデータと機能への限定的なアクセスを許可するための標準化されたフレームワークを提供します。その柔軟なフローとトークン形式により、Web、モバイル、デスクトップ、IoT、API 主導の統合にわたる承認に広く適用可能なプロトコルになります。 OAuth 2.0 は、最新の Web 上のアプリとサービス間のシームレスな相互運用性の基盤となっています。

OAuth 2.0 のベストプラクティス

OAuth 2.0 のセキュリティ上の利点を最大限に活用するには、登録、キー、トークン、および更新トークンに関するベストプラクティスに従うことが重要です。

登録とキーの処理

認証エンドポイントとトークンエンドポイントには HTTPS を使用します。これにより、中間者攻撃から保護されます。
十分なエントロピーを持つ暗号的に強力なキーを生成します。推奨されるキーサイズは、RSA の場合は 2048 ビット、EC の場合は 256 ビットです。
アプリにクライアントシークレットをハードコードしたり、信頼できない相手とシークレットを共有したりしないでください。シークレットをサーバー側に安全に保存します。
認証コードの有効期限を短く、約 10 分に設定します。これにより、傍受の余地が狭まります。
公開されたクライアントシークレットを直ちに取り消し、新しいキーを生成します。

トークンの使用法

アクセストークンの有効期間は 1 時間程度と短くしてください。リフレッシュトークンの有効期限は約 2 週間と長くなります。
アクセストークンは HTTPS 経由でのみ、信頼されたバックエンドにのみ送信します。 URL、ログ、フロントエンドコードにはトークンを決して含めないでください。
API の予想される対象者と一致するようにトークンの対象者を常に検証してください。
発行者が認可サーバーのドメインと一致していることを確認してください。
トークン署名アルゴリズムとキーを既知の信頼できるキーと照合して検証します。

リフレッシュトークン- 信頼できるファーストパーティのアプリとデバイスに対してのみリフレッシュトークンを発行します。サードパーティのクライアントに更新トークンを提供しないでください。

リフレッシュトークンを単一の特定のクライアント ID とユーザー ID の組み合わせにバインドします。
ユーザーがログアウトするか権限が変更されると、リフレッシュトークンを取り消します。再認証時に新しいトークンを発行します。
長期認証と同等の安全なリフレッシュトークン。 HTTPS 経由でのみ送信し、暗号化によってアクセスを制限します。

これらのベストプラクティスに従うことで、OAuth 2.0 が API 認証に堅牢なセキュリティを提供できるようになります。

OAuth 2.0 の脆弱性

OAuth 2.0 は以前の認証プロトコルよりも改善されていますが、適切に実装および保護されていない場合、攻撃者に悪用される可能性がある脆弱性がまだあります。一般的な OAuth 攻撃には次のようなものがあります。

トークンハイジャック - 攻撃者はアクセストークンを盗み、それを使用してリソースへの不正アクセスを取得します。これは、トークンが適切に保護されていないか、安全でないチャネル経由で送信された場合に発生する可能性があります。
認可コードの傍受 - アクセストークンの交換に使用される認可コードは、認可プロセス中に攻撃者によって傍受され、有効なアクセストークンが取得される可能性があります。
クライアントの偽装 - 攻撃者は有効なクライアントになりすまして、認可サーバーをだましてアクセストークンを発行させます。弱いクライアント認証によってこれが可能になります。
ユーザーのなりすまし - 攻撃者はユーザーの資格情報を盗むか推測し、それを使用してユーザーとして認証し、データにアクセスします。
壊れた OAuth フロー - OAuth フローと検証が正しく実装されていないと、エンドポイントが悪用される可能性があります。攻撃者は、redirect_uri 検証、状態パラメータ、コード/トークン発行の欠陥を悪用して、アカウントを侵害する可能性があります。
クロスサイトリクエストフォージェリ (CSRF) - 攻撃者は、フローのブラウザリダイレクトに対する OAuth の依存性を悪用し、認証されたユーザーに無意識のうちに自分に代わってリクエストを作成させることができます。
オープンリダイレクタ - OAuth ログイン後にオープンリダイレクトを許可すると、攻撃者がユーザーをフィッシングサイトにリダイレクトし、資格情報やトークンを盗むことができる可能性があります。

OAuth の悪用を防ぐには、適切な実装が重要です。

状態パラメータとノンスパラメータを使用してCSRFを防止します
安全なクライアントの登録と検証を強制する
暗号化された通信チャネルを利用する
トークンの有効期限を短く設定します
不要になったトークンを取り消す
リフレッシュトークンは慎重かつ慎重に使用してください
検証とリダイレクトについては OAuth のベストプラクティスに従いますOAuth 2.0 は認証のための標準化されたフレームワークを提供しますが、組織は適切な実装、セキュリティ制御、および堅牢なアクセスポリシーを通じて脆弱性を軽減するよう注意する必要があります。 OpenID Connect などの追加プロトコルは OAuth をベースにしてセキュリティを強化しており、継続的な進化の必要性を示しています。

OAuth 2.0 を超えて

OAuth 2.0 は承認のための重要な標準であり、現在でも広く使用されています。ただし、OAuth 2.0 は 10 年以上前の標準であるため、現代のセキュリティの脅威に直面すると、その古さと限界が見え始めています。 OAuth 2.0 では十分ではなくなる主な理由を以下に示します。

モバイルアプリやネイティブアプリではなく、デスクトップと Web 向けに設計 - OAuth 2.0 は、モバイルアプリやネイティブアプリが登場する前の時代に作成されました。これは、Web ブラウザーのコンテキスト外ではうまく機能しないリダイレクトに依存しています。これにより、セキュリティ上の脆弱性が生じる可能性があります。
デフォルトではトークンを暗号化しない - OAuth 2.0 トークンは多くの場合暗号化されずに送信されるため、傍受される可能性があります。仕様では認証フローに https が必要ですが、アクセストークンは平文で送信できます。
ID を検証するための組み込みメソッドはありません - OAuth 2.0 は、承認とアクセス委任に焦点を当てています。ユーザーの身元は確認されません。これにより、なりすまし攻撃の余地が残ります。
トークンの再利用と埋め込みリスク - OAuth 2.0 は 1 回限りの認証を提供しますが、トークンの複数回の使用を妨げません。より幅広いアクセス権を持つトークンはアプリに埋め込まれ、危険にさらされる可能性が広がります。
所有証明の要件なし - トークンを使用する当事者が意図された許可されたユーザーであることを示す暗号証明はありません。これにより、トークンが傍受された場合に大きなリスクが生じます。
制限された暗号化標準 - OAuth 2.0 は、SHA-1 などの古い暗号化のみをサポートします。 SHA-256 などのより強力な最新のアルゴリズムは、コア仕様には組み込まれていません。

脅威が進化するにつれて、それらを防御する OAuth 2.0 の機能は限界に達しつつあります。 OAuth 2.0 は依然として広く使用されていますが、特定のユースケースでは、より堅牢で最新の認証標準に拡張して置き換える必要があります。 OpenID Connect、相互 TLS、WebAuthn などのプロトコルを検討すると、将来のセキュリティを強化するためのオプションが得られます。

OpenID ConnectOpenID Connect は、追加の ID 機能を提供する OAuth 2.0 上に構築された認証プロトコルです。 OAuth 2.0 では、リソースサーバーはアクセスを許可するアクセストークンを受け取りますが、ユーザーの ID に関する情報は提供されません。

OpenID Connect を使用すると、クライアントは認可サーバーによる認証を通じてユーザーの ID を確認できます。これにより、クライアントはユーザーに関する基本的なプロファイル情報を取得できるようになります。 OpenID Connect は、ユーザー認証に関するクレームを含む JWT (JSON Web Token) を利用し、これをクライアントに返すことができます。

OpenID Connect がセキュリティを強化する主な使用例は次のとおりです。

シングルサインオン (SSO) - OpenID Connect により、複数のサイトおよびアプリケーションにわたるシンプルな SSO が可能になります。認証はアイデンティティプロバイダーの認可サーバーによって処理されるため、サイトがそれぞれ独自の認証を処理する必要はありません。
整合性の向上 - ID トークンには、ID プロバイダーによって安全に検証された署名付きクレームが含まれています。これにより、標準の OAuth アクセストークンよりも優れた整合性が保証されます。
ユーザープロファイルアクセス - OpenID Connect はオプションでエンドユーザーのプロファイル情報へのアクセスを提供し、追加の API 呼び出しを必要とせずに、ユーザーが誰であるかについての追加のコンテキストをクライアントに提供します。
ID に対するより高い信頼性 - スコープ、JWT クレーム、および暗号化の使用に関する標準により、基本的な OAuth と比較して、ユーザーが主張する本人であることに対する高い信頼性が提供されます。

要約すると、OpenID Connect は OAuth 2.0 によって提供される承認の上に構築されており、信頼性の高い認証を提供し、ユーザーの ID を検証します。 SSO などのユースケースや ID 保証が重要な場合、OpenID Connect はより安全で堅牢なプロトコルです。

より強力な認証のための相互 TLS

相互 TLS は、クライアントとサーバー間の双方向認証を必要とすることで、従来の TLS よりも強力な認証を提供します。 mTLS では、暗号化された TLS 接続を確立する前に、クライアントとサーバーの両方が自身を識別するための証明書を提供する必要があります。

mTLS 認証の仕組みは次のとおりです。

クライアントは、サーバーにクライアント証明書を送信することによってハンドシェイクを開始します。この証明書は信頼できる認証局 (CA) から発行され、クライアントの ID を検証します。
その後、サーバーは独自のサーバー証明書をクライアントに提供します。この証明書は、サーバーの ID を認証するために、信頼された CA に対して検証されます。- クライアントとサーバーは、双方が互いの証明書を正常に検証した場合に、暗号化された TLS セッションをネゴシエートします。これにより、認証された双方向通信チャネルが作成されます。
クライアントとサーバーは、両端の ID が検証されたことを認識して、暗号化された TLS トンネルを通じて安全にデータを交換できるようになりました。

mTLS は、クライアントに対してサーバーを認証するだけの標準 TLS よりも安全です。 mTLS は相互認証を要求することで、不正なネットワーク接続を防止し、中間者攻撃を阻止します。

mTLS がセキュリティを強化するユースケース:

マイクロサービス間の通信を保護します。 mTLS は、未承認のマイクロサービスがメッシュに参加するのを防ぎます。
内部接続する Kubernetes ポッドの認証。 mTLS は、クラスター内で通信するポッド ID を検証します。
IoT デバイスの通信を保護します。 mTLS は、クライアント証明書を要求することでマシン間の通信をロックダウンします。
銀行取引および金融取引。 mTLS は、金融システム間のトランザクションの整合性を保証します。

実装にはクライアントとサーバーの両方が mTLS をサポートする必要があります。 NGINX のようなロードバランサーは、mTLS 接続を終了し、プレーン TLS モードでトラフィックを中継できます。クライアント SDK を使用すると、バックエンドサービスに接続するモバイルアプリや Web アプリに mTLS 認証を簡単に統合できます。適切なライブラリと負荷分散を使用すると、企業は mTLS セキュリティを大規模に展開できます。

Web認証/FIDO2

WebAuthn (Web 認証) と FIDO2 は、従来のパスワードベースの認証の代替手段を提供する新しい Web 標準です。

WebAuthn を使用すると、Web サイトはパスワードの代わりに公開キー暗号化を使用してユーザーを登録および認証できます。これは、セキュリティキーや生体認証などの認証システムを通じて有効になります。この標準は、FIDO Alliance と World Wide Web Consortium (W3C) によって作成されました。

FIDO2 は、セキュリティキー、生体認証、プラットフォーム認証システムなどの安全な資格情報を使用したパスワードレスの認証方法を可能にする一連の技術仕様です。これは、FIDO (Fast Identity Online) 標準の拡張です。

従来のパスワード認証に対する WebAuthn と FIDO2 の主な利点をいくつか示します。

セキュリティの向上 - パスワードは脆弱であったり、再利用されたり、漏洩されたり、盗まれたり、フィッシング攻撃を受けたりする可能性があります。 WebAuthn は、非対称 (公開キー) 暗号化を使用して、これらの脅威に耐性のある非常に強力な形式の認証を提供します。- ユーザーエクスペリエンスの向上 - パスワードを作成したり覚えたりする必要はありません。ユーザーは指紋またはセキュリティキーを使用して認証するだけで、より速く簡単です。
コストの削減 - 組織は、IT オーバーヘッドを追加するパスワードのリセット、ヘルプデスクへの電話、その他のパスワード関連の問題への対応に費やす時間を削減します。
プライバシー保護 - WebAuthn を使用すると、元の認証情報 (生体認証テンプレートまたは秘密キー) がユーザーのデバイスから流出することはありません。これによりプライバシーが保護されます。
プラットフォーム/デバイスに依存しない - WebAuthn はデスクトップとモバイルデバイス間で動作します。また、ユーザーを特定のプラットフォームやデバイスにロックすることもありません。

全体として、WebAuthn と FIDO2 は、Web 上での認証のセキュリティと使いやすさに関して大きな前進を示しています。これらの標準が広く採用されるにつれて、脆弱なパスワードベースのシステムへの依存は減少するでしょう。

結論

OAuth 2.0 は多くのアプリケーションの認可と認証の標準となっており、ユーザーが資格情報を公開せずにデータへの限定的なアクセスを許可する方法を提供します。ただし、OAuth 2.0 は古いプロトコルであるため、セキュリティ、アクセス範囲、ユーザーエクスペリエンスに関していくつかの制限があります。

新しいプロトコルは、さまざまな方法で OAuth 2.0 を改善することを目指しています。

OpenID Connect は OAuth 2.0 の上に構築され、アイデンティティサービスを追加し、認証と認可とともにアイデンティティの検証を提供します。これは、OAuth 2.0 のセキュリティ脆弱性の一部に対処するのに役立ちます。
相互 TLS は、クライアントとサーバーの両方に証明書ベースの認証を提供し、中間者攻撃を防ぎます。実装はより複雑ですが、相互 TLS は OAuth 2.0 単独と比較して整合性とプライバシーの保護を向上させます。
WebAuthn/FIDO2 は、認証にパスワードの代わりに公開キー暗号化を使用し、フィッシング耐性と改ざん耐性のあるログインを提供します。このプロトコルは、多くの場合、ログイン用の OAuth を完全に置き換えることができます。

全体として、OAuth 2.0 は安全な認証の基礎を築きましたが、その古さはさまざまなレガシー制限に現れています。新しいプロトコルは OAuth に基づいて構築されていますが、セキュリティ、プライバシー、ユーザーエクスペリエンスに関する弱点に対処しています。

ヘルスケア、金融サービス、アイデンティティ管理などの機密性の高いアプリケーションの場合、多層防御を提供するために相互 TLS と WebAuthn などのプロトコルを強く検討する必要があります。コンシューマアプリの場合でも、OpenID Connect を使用して OAuth を強化すると、ユーザー ID と認証の整合性が向上します。このエキサイティングな分野に関するさらなる洞察と最新情報については、引き続き APIRobots をご覧ください。API があなたのビジネスにもたらす可能性のある機会をお見逃しなく。今すぐ API Robots または API 開発庁) までお問い合わせください。一緒に API の可能性を最大限に引き出しましょう。