「オープンオーソライゼーション」を意味するOAuth 2.0は、ウェブサイトまたはアプリケーションが、ユーザーに代わって他のウェブアプリがホストしているリソースに、アクセスできるよう設計された基準です。2012年に OAuth 1.0 の後を継ぎ、現在、事実上、オンライン認可の業界基準となっています。OAuth 2.0 は、ユーザーの認証情報を共有しなくても、ユーザーに代わって、合意されたアクセスを提供し、クライアントアプリがリソースに対して実行できるアクションを規制します。

ウェブが OAuth 2 の主要なプラットフォームですが、仕様には、他のクライアントタイプ（ブラウザーベースのアプリケーションサーバー側のウェブアプリケーション、ネイティブ/モバイルアプリ、コネクテッドデバイスなど）の代理アクセスの取り扱い方法なども記載されています。

OAuth 2.0 は、認可プロトコルであり、認証プロトコルではありません。そのため、このプロトコルは、主にリソースセット（たとえば、リモート API またはユーザーデータ）へのアクセスを付与する手段として設計されています。

OAuth 2.0 はアクセストークンを使用します。アクセストークンとは、エンドユーザーの代わりにリソースにアクセスするための許可を示すデータです。OAuth 2.0 のアクセストークンは、特定の形式に指定されていません。ただし、場合によっては JSON ウェブトークン（JWT）が使用されることがよくあります。トークン発行者が、トークンそのものにデータを含めることができます。また、セキュリティ上の理由で、アクセストークンには有効期限があります。

役割という考え方は、OAuth2.0 認可フレームワークのコア仕様に欠かせません。これは、OAuth 2.0 システムの重要なコンポーネントを次のように定義しています。

• リソースオーナー：保護されたリソースを所有し、アクセス権を与えることができるユーザーまたはシステム。

• クライアント：クライアントとは、保護されたリソースへのアクセスを要求するシステム。リソースにアクセスするには、クライアントは、適切なアクセストークンを保持していなければいけません。

• 認可サーバー：このサーバーは、クライアントからのアクセストークンのリクエストを受信し、認証が成功してリソースオーナーから合意を得たら、アクセストークンを発行します。認可サーバーは、2つのエンドポイントを公開します。認可エンドポイント：インタラクティブな認証とユーザーの合意を取り扱います。トークンエンドポイント：マシンtoマシンに関与します。

• リソースサーバー：ユーザーのリソースを保護し、クライアントからのアクセスのリクエストを受信するサーバー。クライアントからのアクセストークンを受領し、検証した後、適切なリソースをクライアントに返します。

スコープは、OAuth 2.0 の重要なコンセプトです。リソースへのアクセス権を付与する理由を正確に特定するために使われます。許容されるスコープ値、どのリソースに関連しているかは、そのリソースサーバーによります。

OAuth 2 認可サーバーは、リソースオーナーがアクセスを認可した後に、直接、アクセストークンを返すことはできません。その代わり、セキュリティを高めるため、認可コードが返され、それはアクセストークンと交換されます。 加えて、認可サーバーは、アクセストークンとともにリフレッシュトークンも発行します。アクセストークンとは違い、リフレッシュトークンは、通常、有効期限が長く、有効期間が過ぎると新しいアクセストークンと交換することができます。リフレッシュトークンにはこのような特性があるため、クライアントによって安全に保管することができます。

最も基本的な段階では、クライアントは、まず、アクセストークンのリクエスト時にクライアント自身を特定・認証するため、認可サーバーから認証情報、クライアント ID、クライアントシークレットを取得しなければなりません。その後に OAuth 2.0 を使用することができます。

OAuth クライアントは2.0 を使って、アクセスリクエストを発信します（例：モバイルアプリ、ウェブサイト、スマートTVアプリ、デスクトップアプリケーションなど）。トークンリクエスト、エクスチェンジ、レスポンスは、この一般的なフローによって行われます：

1.クライアントは、クライアント ID 、シークレットを ID として提供し、認可（認可リクエスト）を認可サーバーからリクエストします。また、スコープとエンドポイント URI （リダイレクト URI）を提供して、アクセストークンまたは認可コードを送信します。認可サーバーは、クライアントを認証し、リクエストされたスコープが許可されているか確認します。

3.リソースオーナーは、認可サーバーとやり取りを行い、アクセスを付与します。

4.認可サーバーは、グラントタイプ（次のセクションで説明します）に応じてクライアントに認可コードまたはアクセストークンをリダイレクトして戻します。リフレッシュトークンも返されます。

5.クライアントは、アクセストークンとともに、リソースサーバーのリソースにアクセスをリクエストします。

OAuth 2.0 においてグラントとは、クライアントがリソースにアクセスする認可を得るために、実行しなければならない一連の手続きです。認可フレームワークでは、さまざまな状況に対応するため、いくつかのグラントタイプを提供しています：

• 認可コード グラント：認可サーバーがシングルユース認可コードをクライアントに返した後、アクセストークンと交換されます。これは、交換がサーバー側で安全に行われる従来のウェブアプリには最適な選択肢です。認可コードフローは、シングルページアプリ（SPA）とモバイル/ネイティブアプリによって使われる場合があります。ただし、この場合、クライアントシークレットは、安全に保管することはできません。したがって、交換中、認証はクライアント IDの使用のみに限られます。下記の認可コード+PKCE グラントの方が、より良い選択肢と言えるでしょう。

• 暗黙的 グラント：アクセストークンがクライアントに直接返される、簡略化されたフロー暗黙的なフローでは、認可サーバーはコールバック URI のパラメータとして、または フォームPOSTへのレスポンスとして、アクセストークンを返します。最初の選択肢は、トークンの流出の可能性があるため、現在では使われていません。

• コード交換（PKCE）のためのコードグラント+プルーフキー：この認可フローは、認可コード グラントに似ていますが、手続きを追加することで、モバイル/ネイティブアプリおよび SPA への安全性を強化します。

• リソースオーナー認証情報グラントタイプ：このグラントは、クライアントに対し、初めに認可サーバーにパスされた、リソースオーナーの認証情報を取得するよう求めます。そうすることで、完全に信頼されているクライアントに限定されます。認可サーバーへのリダイレクトが全くないというメリットがあるため、リダイレクトができないユースケースに適用できます。

• ： クライアント認証情報グラントタイプ：自動化プロセス、ミクロサービスなどの非インタラクティブなアプリケーションに使用。この場合、アプリケーションは、クライアント ID およびシークレットを使って自らを認証します。

• デバイス認可フロー:：スマートTVなどの入力による制約があるデバイス上のアプリでの使用を可能にするグラント。

• リフレッシュトークングラント：リフレッシュトークンから新しいアクセストークンへの交換が必要なフロー。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。