Open Authorization（OAuth）は、エンドユーザーの保護されたリソース（写真、カレンダー、ソーシャル・メディアの投稿など）へのアクセスを、ユーザー・アカウントへのログインやパスワードを必要とせずに、アプリケーションに許可するオープンス・タンダードの認証フレームワークです。
ユーザーに「Googleでログイン」したり、「アカウント情報へのアクセスを許可」するように求めるWebサイトやサード・パーティー・アプリケーションは、OAuthの一般的なユースケースです。OAuthプロトコルを使用することで、ユーザーは認証情報を共有することなく、これらのアプリケーションにアカウント・データへのアクセスを簡単に許可できます。
OAuthでは、Webアプリケーションに加えて、API、サーバー・サイド・アプリケーション、OSネイティブ・アプリ、モバイル・アプリケーション、スマートTVや家電などのデバイスへのリソース・アクセスも許可できます。場合によっては、OAuthが組織またはビジネス・アカウントに代わってアプリケーションへのアクセスを認可できるため、人間のユーザーが関与しないことがあります。
OAuthは、ログイン・データにアクセスできないようにし、他の機密情報へのアクセスを制限することで、ユーザー、開発者、企業に重要なアクセス管理上のメリットを提供します。また、ユーザー認証情報の共有によるセキュリティー上の脆弱性を回避して、アプリケーションが必要なアカウント情報に簡単にアクセスできるようにします。
セキュアなアクセスを簡素化することで、OAuthは組織が抱える最大のセキュリティ課題のいくつかに対処しやすくなります。たとえば、IBM Institute for Business Valueの調査では、経営幹部の52%が、複雑さがサイバーセキュリティ運用の最大の障害であると回答しています。
ある小規模なソフトウェア開発者のチームが、2007年にOAuth 1.0をリリースしました。このプロトコルの最初のバージョンは、ユーザーがユーザー名とパスワードをサードパーティーのサービスと共有する必要があったWebベースの認証の代替案として設計されました。しかし、OAuth 1.0は、Webサイトに対してのみ認証フローを提供しました。
2012年、Internet Engineering Task Force（IETF）は、RFC 6749およびRFC 6750として、OAuth 2.0をリリースしました。RFC（Request for Comments）は、インターネット通信プロトコルについて説明したIETFの文書です。RFC 6749は、OAuth 2.0のコア・フレームワークであり、RFC 6750はフレームワークがアクセス・トークンを使用する方法を定義しています。
この更新されたOAuthバージョンでは、プロトコルがWebブラウザを超えて拡張され、アプリケーション、API、デバイスの認証機能が組み込まれました。OAuth 2.0は現在、OAuth 1.0に代わって業界標準となっています。
OAuthは、ユーザー名とパスワードに依存する他のフレームワークとは異なり、アクセス・トークンに基づいた認可プロトコルです。アクセス・トークンは、アプリケーションがアクセスを許可される特定のリソースを決定する情報です。OAuthプロトコルは、認可リクエスト・プロセスの各コンポーネントがアクセス・トークンを承認、定義、管理する方法を定義します。
OAuthトークンは、データを安全に送信できるため、一般にJSON Web Token（JWT）標準を使用します。
OAuthフレームワークの主な構成要素は次のとおりです。
FacebookやGoogleアカウントなど、アプリケーションがアクセスしようとしているアカウントを所有するエンドユーザーです。リソース所有者は、アプリケーションがそのアカウント内の特定の保護されたリソース（写真や個人データなど）にアクセスすることに同意します。リソース所有者は、企業またはビジネス・アカウントである場合もあります。
ユーザーに代わって、保護されたリソースを保存するサーバーです。リソース・サーバーは、クライアントから受け取ったOAuthトークンを受け入れて検証し、リソース所有者が同意したユーザー・データを提供します。
クライアントは、アクセスを要求するアプリケーション、Webサイト、API、またはデバイスです。クライアントIDを提示して、認可サーバーに認可を要求します。リソース所有者が同意すると、クライアントはリソース・サーバー上の保護されたリソースにアクセスするためのアクセス・トークンを受け取ります。
OAuthプロトコルを駆動するプライマリー・サーバーです。2つのエンドポイントを操作して、リソース・サーバーへのアクセスを許可します。
認可エンドポイントは、特定の保護対象のリソースへの同意をリソース所有者に求めます。次に、トークン・エンドポイントは、OAuthクライアントからトークン・リクエストを受け取り、リソースへのアクセスを許可する新しいアクセス・トークンを生成します。
スコープは、リソース・サーバー上の保護されたリソースへのアクセス・パラメーターです。
例えば、リソース所有者は、Eメール、ファイル、写真などのデータへのアクセスについて同意を求められることがあります。スコープは、クライアントのアクセスをそれらの項目のみに制限します。
OAuthフローの基本的な概要は次のとおりです。
アプリケーションにアクセス・トークンを提供する手順は、認可グラントまたは認可フローと呼ばれます。次のような、さまざまな種類のアプリケーション、デバイス、またはAPIに使用できるさまざまなグラント・タイプとOAuthフローがあります。
このグラント・タイプは通常、Webアプリケーションとモバイル・アプリケーションに使用されます。認可コード・フローでは、認可サーバーがクライアントにワンタイム認可コードを提供します。その後、クライアントはその認可コードを認可サーバーのトークン・エンドポイントからのアクセス・トークンと交換できます。
このフローにより、認可コード・グラントのセキュリティーを強化し、コード・インジェクション攻撃からアプリを保護できます。この種の攻撃は、アプリを騙して悪意のあるコードを実行させて、アプリの動作を変える可能性があります。
PKCEは、アクセス・トークンが発行される前に、認可サーバーでクライアントを認可する「クライアント・シークレット」を追加します。正規のクライアントだけがシークレットを持っているため、悪意のある攻撃者がクライアントになりすまして悪意のあるコードをインプットすることはできません。
このグラント・タイプは、自動化されたプロセス、マシン間のやり取り、マイクロサービスなど、人間のユーザーが関与しない状況向けに設計されています。
アプリケーションは、機能を実行するために必要なシステム・リソースへのアクセスを許可されますが、エンドユーザーのリソースへのアクセスは許可されません。たとえば、クライアントの認可グラントにより、天気予報アプリがAPIにアクセスして最新の予報データを取得できるようになります。
JavaScript Webアプリケーションのよりシンプルなフローを提供します。認可コード・グラントとは異なり、暗黙的フローでは、アクセス・トークンが発行される前に認可コードを必要としません。
代わりに、ユーザーが同意した後で、アクセス・トークンは、アクセスを要求しているアプリケーションにユーザーを返すリダイレクトUniform Resource Identifier（URI）に含まれます。アプリは、URIからアクセス・トークンを取得します。
アクセス・トークンの有効期限が切れた場合、このグラント・タイプはアプリケーションに新しいアクセス・トークンと交換できるリフレッシュ・トークンを提供します。リフレッシュ・トークンがないと、アプリケーションが新しいアクセス・トークンを受け取るために、エンドユーザーがもう一度同意する必要があります。
基本的な違いは、シングル・サインオン（SSO）がユーザー認証プロトコルであり、OAuthは認可プロトコルである点です。
SSOでは、多くの場合、アイデンティティー・プロバイダー（IdP）と、拡張マークアップ言語（ XML ) に基づくセキュリティー・アサーション・マークアップ言語（SAML）を用いて、ユーザー名とパスワードによりユーザーのデジタルIDを認証します。
OAuthはユーザーを認証しませんが、システム・リソースへのアクセスを認可します。SSOソリューションでは、OAuthを使用して、認証されたユーザーが企業全体のアプリケーションやサービスに簡単にアクセスできるようにすることがあります。
OpenID Connect（OIDC）は、OAuth 2.0をベースに構築された認証プロトコルです。OpenID Connectは、連携してユーザーのIDを検証し、OAuthによってそのユーザーがリソースやサービスにアクセスすることを承認できます。