OAuth (Open Authorization の略) は、サービスがリソースをすばやく安全に共有してシームレスなユーザー エクスペリエンスを実現する、広く普及している標準化された API プロトコルです。OAuth の使用例として、グリーティング カード サービスにフォト ライブラリへのアクセスを許可してカスタムのホリデー カードを作成したり、オンライン小売業者のサイトにログインするため Google アカウントを使用することが挙げられます。
この記事では、OAuth とは何か、どのように機能するのか、なぜ重要なのか、そして API とどのように連携するのかを詳しく解説します。
OAuth とは?
OAuth は、Web サイトやアプリケーションが、ユーザーに代わって他の Web アプリケーションがホストするリソースにアクセスできるように設計されたオープン スタンダードです。利便性とセキュリティやプライバシーのバランスをとる上で重要な役割を果たします。OAuth 標準は、HTTP 接続を使用した安全な委任アクセスを提供する認可メカニズムの構築に使用されます。
ユーザーは、ユーザー名やパスワードを共有したり、サードパーティにアカウントへの直接アクセスを与えることなく、アプリケーションや Web サイトのデータをサードパーティと共有できます。これにより、サードパーティ アプリケーションがセキュリティ侵害に遭っても、ユーザーの認証情報は安全に保たれることが保証されるなどのメリットがあります。
Facebook、Google、GitHub、Twitter、LinkedIn、Microsoft、Amazon などは、サードパーティ アプリケーションに代わって認証情報を処理することができます。
OAuth の例
OAuth は、気付かないうちに目にしているかもしれません。OAuth の使用例として、以下のようなものがあります。
Spotify に、あなたの代わりにソーシャル メディア アカウントに投稿する許可を与える
デジタル フォト フレーム アプリに、Google Photos から最新の画像を取得する許可を与える
新しいユーザー名やパスワードを作成するのではなく、Facebook を使用してフード デリバリー サイトにログインする
これらの例は、ユーザー エクスペリエンスに影響する比較的時間のかかるプロセスを合理化する方法を示しています。
特定の権限のみが付与され、サードパーティのアプリやサービスがアクセスまたは変更できる内容に関して明確に説明されています。一度許可を与えると、サードパーティ アプリは、機密情報を処理または保存することなく、ユーザー エクスペリエンスの一部としてそのデータを使用できます。
これらのシナリオでは、ユーザーはより優れた体験が得られ、サービスやサイトを作成する開発者や組織はセキュリティ リスクを最小限に抑えられます。
認証と認可
上記の説明から、OAuth は API 認証サービスのように思われるかもしれませんが、実際にはそうではありません。
OAuth は認可、つまり、ユーザーがリソースにアクセスするための権限や特権を持っているかどうかを確認することに重点を置いています。ユーザー名とパスワードを要求したり、電話をトークンとして使用することは認証、つまり、身元の確認です。
分かりやすいとたとえで説明すると、認証は空港に入場するために身分証明書を見せること、認可は特定のエリアにアクセスできるかどうかを決めることです。
認証プロセスは、Google や Facebook などの ID プロバイダーとして機能するアプリケーションまたはサイトによって処理されます。
認可標準である OAuth は直接認証を管理しませんが、認証済みのユーザーに適切なリソースへのアクセスを許可することができます。また、認証ツールや ID プロバイダー ツールと連携してアクセスを委任するように構成することもできます。
OAuth とシングル サインオン (SSO)
OAuth とシングル サインオンは似ていると思うかもしれません。OAuth は、SSO サービスからアプリケーションに認証を渡すのによく使用されますが、Microsoft の Active Directory Federation Services、Google アカウント、GitHub 統合のようなシングル サインオンのフェデレーション認証システムではありません。
また、Pluggable Authentication Modules (PAM) のような認証 API でも、OpenID Connect のような ID プロバイダーでもありませんが、これらのいずれとも連携できます。
OAuth と SAML
OAuth と SAML はどちらもシングル サインオン (SSO) でよく使用されるプロトコルですが、目的は異なります。OAuth は認可、つまり権限や特権に重点を置いているのに対し、SAML (Security Assertion Markup Language) は認証、つまり身元の確認に重点を置いています。
SAML は広く使用されている認証のオープン スタンダードで、ID プロバイダーとサービス プロバイダー間の認証データの交換を可能にします。簡単に言うと、SAML はアプリやサービスがユーザーが本人であることを確認する方法です。
SAML は SSO と同じではありませんが、SSO を可能にします。
SAML 仕様では、次の 3 つの役割が定義されています。
- ユーザー: アプリケーションにアクセスしようとしているユーザー
- ID プロバイダー (IdP): デジタル ID を保存、管理、確認する SSO サービス
- サービス プロバイダー (SP): ユーザーが使用しているアプリまたはサービス
サービス プロバイダーと連携する場合、ID プロバイダーは SAML 認証を活用できます。SAML は、イントラネットなどのより複雑な環境にも使用できます。イントラネットでは、1 回の認証プロセスでユーザーが複数のサービスにアクセスできます。
同様に、OAuth は OpenID とは異なります。OpenID は、ユーザーが Google アカウント ログインなどの認証済み ID を YouTube などの他のサービスに拡張できるようにする ID プロバイダーです。
OAuth 1.0 と 2.0
OAuth 2.0 について見聞きしたことがある方もいらっしゃるでしょう。「2.0」というバージョン番号から推測できるように、OAuth 2.0 は OAuth 1.0 を完全に書き直した OAuth の最新バージョンです。この 2 つは互換性がなく、OAuth 1.0 は廃止されました。
2012 年に導入された OAuth 2.0 では、認証プロセスが一新されました。この新しいバージョンは実装が容易で、リソース配信と認可が区別され、従来の Web ブラウザーだけでなく幅広いデバイスをサポートしています。これらの変更は、OAuth 1.0 から学んだ教訓と、Microsoft、Google、Facebook、Twitter、Intuit などの主要企業との議論を基に導入されました。
OAuth を使用するメリット
ユーザーにとって、OAuth の最も明白な利点は、サイトやサービスに迅速にアクセスできることです。企業にとっては、取引完了までのハードルが減ることで、より多くの取引が成立する可能性があります。開発者にとっては、ユーザーの機密情報を保護できることです (顧客情報の取り扱いに慎重な企業は、この点も高く評価する傾向があります)。
さらに、OAuth は、安全性とシンプルさを兼ね備えています。サードパーティ サービスが顧客データにアクセスできるようにするには、複雑なインフラストラクチャが必要ですが、その構築には消極的な企業が多いでしょう。認証メカニズムの実装は複雑であり、適切に行わないと、多額の費用がかかります。また、ユーザー名/パスワードの組み合わせを可能な限り使用しないことが一般的に推奨されます。
OAuth を適切に実装すると、1 つ以上のサービスに認証プロセスをアウトソースして、サービスが提供するエンタープライズ グレードのベスト プラクティスをエンドツーエンドに適用するリソースを利用できます。
OAuth が重要な理由
ユーザー名とパスワードによるオンライン リソースへのアクセスは便利ですが、代償を伴います。この方法はシンプルですが、プライバシーを制限し、セキュリティを損なう可能性があります。
たとえば、あなたが会計事務所に勤めていて、顧客の財務記録を政府の税務当局が利用できるようにしたいとします。1 つの選択肢は、税務当局が顧客の書類にアクセスするための認証情報を作成することです。しかしそれには、強固な認証/認可プロセスを備えたソフトウェア モジュール全体の構築が必要になります。また、財務当局が想定通りにサイトを利用することが前提ですが、それは期待すべきではありません。
そこで考えられるソリューションの 1 つが OAuth です。
財務書類が、インターネットに接続された Web サーバーと、そのサーバー上でホストされている会計アプリケーションからアクセスできる安全性の高いバックエンド サーバーにあるとします。この場合、税務サービスが財務書類にアクセスすることを顧客が認可できるようにするとともに、税務サービスが顧客に代わって財務書類にアクセスするたびに税務サービスを認証する必要があります。OAuth はこれを実現します。
OAuth の仕組み
OAuth の仕組みを正しく理解するため、いくつかの重要な用語について見てみましょう。
クライアントは、アクセスを要求するユーザーまたはエンティティです。上記の例では、顧客に代わって財務文書にアクセスする税務当局サービスがこれに当たります。通常、クライアントは Web ブラウザーを介してリソース プロバイダーと連携します。
リソース所有者とは、財務書類を所有し管理している顧客であり、OAuth の用語では財務書類がリソースに当たります。
リソース サーバーは、会計事務所が運用している Web サーバーです。
認可サーバーは、クライアントがリソース所有者の適切なリソースにアクセスできるようにする認証トークンを提供するサービスです。認可サーバーとリソース サーバーは同じであることが一般的ですが、常に同じであるとは限りません。
OAuth 認可フロー
認可フローは、一般的に次のように機能します。
- ユーザーはクライアント アプリケーション (税務当局サービス) にログインし、クライアント アプリケーションはリソース サーバー (会計事務所の Web サイト) 上のリソース (財務書類) へのアクセスを要求します。
クライアント アプリケーションは、ユーザーのブラウザーを認可サーバー (この例では、これも会計事務所の Web サイト) にリダイレクトします。
認可サーバーは、ユーザーが資格情報を入力するためのログイン ページを表示します。
ユーザーが ID を認証し、クライアントにリソースへのアクセスを許可すると、認可サーバーはブラウザーをクライアント アプリケーションにリダイレクトし、認可コードを提供します。
クライアント アプリケーションは、認可コードを認可サーバーからのアクセス トークンおよび更新トークンと交換します。
クライアント アプリケーションは以降、ユーザーに代わってリソースへのアクセスを要求するたびに、アクセス トークンをリソース サーバーに提示します。
アクセス トークンは、不透明な文字列 (一見ランダムな文字列) です。クライアント アプリケーションは、アクセス トークンをもって、特定のリソースへのアクセスが許可されていることをリソース サーバーに示します。
認可サーバーは、アクセス トークンの有効期間を設定します。
クライアント アプリケーションは、アクセス トークンと一緒に更新トークンも受信します。アクセス トークンの期限が切れたら、クライアント アプリケーションはこの更新トークンを認可サーバーに提示して、新しいアクセス トークンを要求できます。
注意: どのクライアントでもリソースへのアクセスを要求できるわけではありません。認可サーバーは、OAuth 経由で認可を要求できるクライアントのリストを保持しています。
この例では、税務当局サービスは会計事務所と契約を結ぶ必要があります。認可サーバーは、OAuth での接続を許可された各クライアントにクライアント ID とシークレットを付与します。この情報は、クライアントが認可コードまたはアクセス トークンを要求する際のクライアント認証に使用されます。
API で OAuth を使用する方法
組織や開発者は、OAuth システムの強化されたセキュリティに影響を与えることなく、リソース アクセスにプログラム機能を追加できます。
たとえば、会計事務所が顧客に、税務当局のモバイル アプリからリソースへのアクセス許可を与えられるようにしたいとします。この場合、会計事務所は OAuth を API に統合することができます。
API は OAuth 認可コードとアクセス トークンを生成するエンドポイントを開きます。このエンドポイントは、クライアント ID とクライアント シークレットをパラメーターとして受け取る必要があります。トークンは、パラメーターとして API エンドポイントの呼び出し元に返されます。
OAuth、認証、認可に関するその他の役立つ情報
トークンベースの認可メカニズムを使用してユーザーにさまざまなエンタープライズ アプリケーションへのアクセスを許可することは、セキュリティを維持するために不可欠です。今日の状況では、アプリケーション、マイクロサービス、API 間のシームレスな情報転送は大きな価値をもたらし、優先度も高まっています。
Kong Gateway には、一般的な認証、セキュリティ、分析、監視の要件に対応できる豊富なプラグイン エコシステムがあります。
Kong と OAuth を使ってみませんか? 詳細については、チュートリアルを確認するか、デモをリクエストしてください。
Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。
参照記事: 2023 年 1 月 26 日
© Kong Inc. 2024
「What is OAuth?」
