OAuth 2の概要

リソースの所有者は、_application_にアカウントへのアクセスを許可する_user_です。 ユーザーのアカウントへのアプリケーションのアクセスは、付与された承認の「スコープ」に制限されます（例： 読み取りまたは書き込みアクセス）。

リソースサーバーは保護されたユーザーアカウントをホストし、承認サーバーは_user_のIDを確認してから、_application_にアクセストークンを発行します。

アプリケーション開発者の観点から見ると、サービスの* API *はリソースと承認サーバーの両方の役割を果たします。 これらの両方の役割を組み合わせて、_Service_または_API_の役割と呼びます。

クライアントは、_user_のアカウントにアクセスする_application_です。 許可する前に、ユーザーが許可する必要があり、APIによって許可を検証する必要があります。

アプリケーションが登録されると、サービスは_client identifier_および_client secret_の形式で「クライアント資格情報」を発行します。 クライアントIDは、アプリケーションを識別するためにサービスAPIによって使用される公開された文字列であり、ユーザーに提示される承認URLを構築するためにも使用されます。 クライアントシークレットは、アプリケーションがユーザーのアカウントへのアクセスを要求するときに、サービスAPIに対してアプリケーションのIDを認証するために使用され、アプリケーションとAPIの間でプライベートに保つ必要があります。

まず、ユーザーには次のような認証コードのリンクが与えられます。

リンクコンポーネントの説明は次のとおりです。

ユーザーがリンクをクリックすると、最初にサービスにログインして身元を認証する必要があります（既にログインしている場合を除く）。 次に、サービスによって、アカウントへのアプリケーションアクセスを_authorize_または_deny_するように求められます。 次に、アプリケーションの承認プロンプトの例を示します。

image：https：//assets.digitalocean.com/articles/oauth/authcode.png [認証コードリンク]

この特定のスクリーンショットはDigitalOceanの承認画面のものであり、「Thedropletbook App」が「[email protected]」のアカウントへの「読み取り」アクセスの承認を要求していることがわかります。

ユーザーが[アプリケーションの承認]をクリックすると、サービスは、ユーザーエージェントを、_authorization code_と共にクライアント登録中に指定されたアプリケーションリダイレクトURIにリダイレクトします。 リダイレクトは次のようになります（アプリケーションが「dropletbook.com」であると仮定）：

アプリケーションは、_client secret_を含む認証詳細とともに認証コードをAPIトークンエンドポイントに渡すことにより、APIからアクセストークンを要求します。 DigitalOceanのトークンエンドポイントへのPOSTリクエストの例を次に示します。

認証が有効な場合、APIはアクセストークン（およびオプションで更新トークン）を含む応答をアプリケーションに送信します。 応答全体は次のようになります。

これで、アプリケーションが承認されました！ トークンが期限切れになるか、取り消されるまで、トークンを使用して、アクセス範囲に制限されたサービスAPIを介してユーザーのアカウントにアクセスできます。 更新トークンが発行された場合、元のトークンの有効期限が切れている場合、それを使用して新しいアクセストークンを要求できます。

暗黙的な付与タイプを使用すると、ユーザーに認証リンクが表示され、APIからトークンが要求されます。 このリンクは、コードではなく_token_を要求していることを除いて、認証コードリンクと同じように見えます（response type“ token”に注意してください）：

ユーザーがリンクをクリックすると、最初にサービスにログインして身元を認証する必要があります（既にログインしている場合を除く）。 次に、サービスによって、アカウントへのアプリケーションアクセスを_authorize_または_deny_するように求められます。 次に、アプリケーションの承認プロンプトの例を示します。

image：https：//assets.digitalocean.com/articles/oauth/authcode.png [認証コードリンク]

「Thedropletbook App」が「[email protected]」のアカウントへの「読み取り」アクセスの許可を要求していることがわかります。

ユーザーが[アプリケーションの承認]をクリックすると、サービスはユーザーエージェントをアプリケーションリダイレクトURIにリダイレクトし、アクセストークンを含むURIフラグメントを含めます。 これは次のようになります。

ユーザーエージェントはリダイレクトURIに従いますが、アクセストークンは保持します。

アプリケーションは、ユーザーエージェントが保持している完全なリダイレクトURIからアクセストークンを抽出できるスクリプトを含むWebページを返します。

ユーザーエージェントは提供されたスクリプトを実行し、抽出されたアクセストークンをアプリケーションに渡します。

これで、アプリケーションが承認されました！ トークンが期限切れになるか、取り消されるまで、トークンを使用して、アクセス範囲に制限されたサービスAPIを介してユーザーのアカウントにアクセスできます。

ユーザーがアプリケーションに資格情報を提供すると、アプリケーションは承認サーバーにアクセストークンを要求します。 POSTリクエストは次のようになります。

ユーザー資格情報がチェックアウトされると、承認サーバーはアクセストークンをアプリケーションに返します。 これで、アプリケーションが承認されました！

注： DigitalOceanは現在、パスワード資格情報の付与タイプをサポートしていないため、リンクは「oauth.example.com」にある架空の承認サーバーを指します。

アプリケーションは、資格情報、クライアントID、およびクライアントシークレットを承認サーバーに送信することにより、アクセストークンを要求します。 POSTリクエストの例は次のようになります。

アプリケーションの資格情報がチェックアウトされると、承認サーバーはアクセストークンをアプリケーションに返します。 これで、アプリケーションは独自のアカウントを使用することが承認されました！

注： DigitalOceanは現在、クライアント資格情報付与タイプをサポートしていないため、リンクは「oauth.example.com」にある架空の承認サーバーを指します。