OAuth の説明
OAuth は、パスワードなどの個人情報が漏洩することなく、1 つのアプリやサービスが別のアプリやサービスにサインインすることを承認できる技術的標準です。“Facebook でサインインしますか?” や “このアプリケーションがアカウントにアクセスすることを許可しますか?” などのメッセージが表示されたことがある場合、OAuth の実際の動作を見たことになります。
OAuth は Open Authorization の略です (認証とみなされることがありますが、これは正しくありません)。認証は、ID を検証するプロセスです。OAuth には ID も含まれますが、その目的は、新しいアカウントを作成することなく、さまざまなアプリやサービスにシームレスに接続するためのアクセス許可を付与することです。OAuth では、資格情報を明らかにすることなく、2 つのアプリがデータの一部を共有することを承認するオプションを提供することで、よりシンプルなエクスペリエンスを提供します。利便性とセキュリティのバランスを取ります。
OAuth は、ハイパーテキスト転送プロトコル (HTTP) で動作するように設計されています。アクセス トークンを使用して ID を証明し、ユーザーに代わって別のサービスと対話できるようにします。この 2 番目のサービスでデータ侵害が発生した場合、最初のサービスの資格情報は安全に保たれます。OAuth は広く採用されているオープン標準のプロトコルであり、Web サイトやアプリのほとんどの開発者が使用しています。
重要な点として、OAuth では、サード パーティのアプリまたはサービスにデータへの無制限のアクセスが許可されることはありません。プロトコルの一部は、サード パーティがアクセスできるデータとそのデータで何ができるかを指定することです。このような制限を設定し、ID 全般を保護することは、多くのユーザーが機密性の高い独自の情報にアクセスできるビジネス シナリオで特に重要です。
OAuth のしくみ
OAuth を安全に使用できるようにしているのは、アクセス トークンです。アクセス トークンとは、ユーザーとトークンが意図されているリソースに関する情報を含むデータの一部のことです。トークンには、データ共有のための特定のルールも含まれます。
たとえば、ソーシャル メディア プロファイルの写真を写真編集アプリと共有したいが、一部の写真にのみアクセスできるようにしたいかもしれません。また、ダイレクト メッセージや友達一覧へのアクセスも必要ありません。トークンは、承認したデータへのアクセスのみを承認します。また、アプリケーションがそのトークンを使用できるタイミング (1 度のみの使用または定期的な使用など) と、有効期限を制御するルールも存在する場合があります。
ほとんどの場合、OAuth プロセスはマシン間の対話であり、ユーザーのタッチポイントはほんのわずかです。一部のシナリオでは、ソフトウェアによってバックグラウンドでサイレントに処理されるため、承認を提供する必要がない場合があります。これに関する OAuth の 2 つの例として、ID プラットフォームがリソース間の接続を処理して多数のユーザーの IT 摩擦を減らすエンタープライズ作業シナリオや、一部のスマート デバイス間の対話があります。
OAuth テクノロジの例
面倒な作業 (この場合は複数のアプリでアカウントを手動で作成する作業) を簡素化する多くのテクノロジと同様に、OAuth はアプリ作成者によってほぼ汎用的に採用されています。ユーザーや企業によるさまざまなユース ケースがあります。
OAuth の 1 つの例を示すために、コラボレーション ツールとして Microsoft Teams を使用していて、共同作業を行っている組織内外のユーザーに関する詳細情報にアクセスしたいとします。LinkedIn 統合を有効にして、Teams から離れることなく、ユーザーの詳細を確認したり、ユーザーと対話したりできるようにします。すると、Microsoft と LinkedIn は OAuth を使用して、アカウントと Microsoft ID のリンクを承認します。
OAuth を使用するもう 1 つのシナリオは、予算アプリをダウンロードして、アラートやグラフなどの視覚的な補助機能を使用して支出を追跡する場合です。これらの動作をアプリが行うには、アプリが銀行データの一部にアクセスする必要があります。銀行口座をアプリにリンクする要求を開始し、口座の残高と取引へのアクセスのみを承認できます。アプリと銀行は OAuth を使用して、銀行のサインイン資格情報をアプリに公開することなく、ユーザーの代わりにこの情報交換を行います。
OAuth のもう 1 つの例は、GitHub を使用している開発者が、アカウントと統合して自動コード レビューを実行できるサードパーティ製アプリがあることがわかった場合です。GitHub Marketplace に移動し、アプリをダウンロードします。その後、GitHub ID を使用してアプリとの接続を承認するように求められます。このプロセスが OAuth を使用して処理されます。すると、レビュー アプリは、毎回両方のサービスにサインインしなくてもコードにアクセスできます。
OAuth 1.0 と OAuth 2.0 の違いは何ですか?
元の OAuth 1.0 は Web サイト専用に開発されました。現在は広く使用されていません。これは、OAuth 2.0 はアプリと Web サイトの両方向けに設計されており、より高速かつ簡単に実装できるためです。OAuth 1.0 は OAuth 2.0 のようにスケーリングしません。また、OAuth 2.0 で可能な認可フローが 6 つであるのに対し、OAuth 1.0 では 3 つだけです。
OAuth の使用を検討している場合は、最初からバージョン 2.0 を使用することをおすすめします。残念ながら、OAuth 1.0 を OAuth 2.0 にアップグレードすることはできません。OAuth 2.0 は、OAuth 1.0 の抜本的な再設計を意図しており、いくつかの主要なテクノロジ企業がその設計に関するフィードバックを提供しました。Web サイトでは OAuth 1.0 と OAuth 2.0 の両方がサポートされますが、作成者は 2.0 が 1.0 を完全に置き換えることを意図しました。
OAuth とOIDC の比較
OAuth と Open ID Connect (OIDC) は密接に関連するプロトコルです。ユーザーの代わりに、1 つのアプリケーションに別のアプリケーションのリソースへのアクセス権を付与する役割を果たすという点で似ています。違いは、OAuth はリソースにアクセスするための承認に使用されますが、OIDC は個人の ID の認証に使用される点です。どちらも、関係のない 2 つのアプリがユーザー データを損なうことなく情報を共有できるようにする役割を持っています。
通常、ID プロバイダーは OAuth 2.0 と OIDC を併用します。OIDC は、ID レイヤーを追加することで OAuth 2.0 の機能を強化するために特別に開発されました。OIDC は OAuth 2.0 上に構築されているため、OAuth 1.0 と下位互換性がありません。
OAuth の使用を開始する
Web サイトやアプリで OAuth 2.0 を使用すると、ID 認証プロセスを簡素化することで、ユーザーや従業員のエクスペリエンスを大幅に向上させることができます。開始するには、組み込みのセキュリティでユーザーとデータを保護する ID プロバイダー ソリューション (Microsoft Entra など) に投資します。
Microsoft Entra ID (旧 Azure Active Directory) では、OAuth 2.0 のすべてのフローがサポートされます。アプリ開発者は、ID を標準ベースの認証プロバイダーとして使用して、エンタープライズ規模の最新の ID 機能をアプリに統合できます。IT 管理者は、これを使用してアクセスを制御できます。
Microsoft Security の詳細情報
-
-
Microsoft Entra ID (旧 Azure Active Directory)
強力な認証とリスクベースのアダプティブ アクセスを使用して、リソースとデータへのアクセスを保護します。
-
-
-
-
よく寄せられる質問
-
OAuth は Open Authorization の略であり、パスワードなどの個人情報が漏洩することなく、1 つのアプリやサービスが別のアプリやサービスにサインインすることを承認できる技術的標準です。アプリがプロフィール情報にアクセスするための認可を要求するとき、OAuth を使用していることになります。
-
OAuth は、アクセス トークンを交換することによって機能します。アクセス トークンとは、ユーザーとトークンが意図されているリソースに関する情報を含むデータの一部のことです。あるアプリまたは Web サイトは、ユーザーに関する暗号化された情報を別のアプリまたは Web サイトと交換し、データ共有に関する特定のルールを含みます。また、アプリケーションがそのトークンを使用できるタイミングと、有効期限を制御するルールも存在する場合があります。ほとんどの場合、OAuth プロセスはマシン間の対話であり、ユーザーのタッチポイントがあるとしてもほんのわずかです。
-
多くの企業では、OAuth を使用して、ユーザーのパスワードや機密データを漏洩させることなく、サードパーティ製のアプリや Web サイトへのアクセスを簡素化しています。Google、Amazon、Microsoft、Facebook、Twitter のすべての企業で、購入の簡素化など、さまざまな目的でアカウントに関する情報を共有するために使用しています。Microsoft ID プラットフォームでは、OAuth を使用して、職場と学校のアカウント、個人アカウント、ソーシャル アカウント、ゲーム アカウントのアクセス許可を承認します。
-
OAuth と Open ID Connect (OIDC) は密接に関連するプロトコルです。ユーザーの代わりに、1 つのアプリケーションに別のアプリケーションのリソースへのアクセス権を付与する役割を果たすという点で似ています。ただし、OAuth はリソースにアクセスするための承認に使用されますが、OIDC は個人の ID の認証に使用されるという違いがあります。どちらも、関係のない 2 つのアプリがユーザー データを損なうことなく情報を共有できるようにする役割を担っています。
-
OAuth 2.0 は、ほぼ古い形式になっている OAuth 1.0 の抜本的な再設計として設計されたため、OAuth 1.0 と OAuth 2.0 の間には多くの違いがあります。OAuth 1.0 は Web サイト専用に開発されましたが、OAuth 2.0 はアプリと Web サイトの両方向けに設計されています。OAuth 2.0 は、より高速かつ簡単に実装でき、OAuth 1.0 では 3 つの認可フローを実行できるのに対し、6 つの認可フローが可能です。
Microsoft 365 をフォローする