OAuth 2の概要

前書き

OAuth 2は、アプリケーションがFacebook、GitHub、DigitalOceanなどのHTTPサービス上のユーザーアカウントへの制限付きアクセスを取得できるようにする承認フレームワークです。 ユーザーアカウントをホストするサービスにユーザー認証を委任し、ユーザーアカウントへのアクセスをサードパーティのアプリケーションに許可することで機能します。 OAuth 2は、Webおよびデスクトップアプリケーション、モバイルデバイスの承認フローを提供します。

この情報ガイドは、アプリケーション開発者向けであり、OAuth 2の役割、許可付与タイプ、ユースケース、フローの概要を提供します。

OAuthロールを始めましょう!

OAuthロール

OAuthは4つの役割を定義します。

  • リソース所有者

  • クライアント

  • リソースサーバー

  • 認可サーバー

次のサブセクションで各役割の詳細を説明します。

リソース所有者:User

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

リソース/認可サーバー:API

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

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

クライアント:Application

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

抽象プロトコルフロー

OAuthロールが何であるかがわかったので、OAuthロールが一般に相互にどのように相互作用するかを示す図を見てみましょう。

image:https://assets.digitalocean.com/articles/oauth/abstract_flow.png [Abstract Protocol Flow]

図のステップのより詳細な説明はここにあります:

  1. _application_は、_user_からサービスリソースにアクセスするための承認を要求します

  2. _user_がリクエストを承認した場合、_application_は承認付与を受け取ります

  3. application_は、自身のIDの認証と許可付与を提示することにより、_authorization server(API)からのアクセストークンを要求します。

  4. アプリケーションIDが認証され、許可付与が有効な場合、authorization server(API)はアプリケーションにアクセストークンを発行します。 承認が完了しました。

  5. application_は_resource server(API)からリソースを要求し、認証用のアクセストークンを提示します

  6. アクセストークンが有効な場合、resource server(API)は_application_にリソースを提供します

このプロセスの実際のフローは、使用中の許可付与タイプによって異なりますが、これは一般的な考え方です。 後のセクションで、さまざまな種類の補助金について検討します。

アプリケーション登録

アプリケーションでOAuthを使用する前に、アプリケーションをサービスに登録する必要があります。 これは、サービスのウェブサイトの「開発者」または「API」部分にある登録フォームを介して行われます。登録フォームでは、次の情報(およびおそらくアプリケーションに関する詳細)を提供します。

  • アプリケーション名

  • 申請ウェブサイト

  • リダイレクトURIまたはコールバックURL

リダイレクトURIは、ユーザーがアプリケーションを承認(または拒否)した後にサービスをリダイレクトする場所です。したがって、承認コードまたはアクセストークンを処理するアプリケーションの部分です。

クライアントIDとクライアントシークレット

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

認可付与

上記の_Abstract Protocol Flow_では、最初の4つのステップは、許可付与とアクセストークンの取得をカバーしています。 許可付与タイプは、アプリケーションが承認を要求するために使用する方法と、APIでサポートされる付与タイプによって異なります。 OAuth 2は4つの許可タイプを定義します。それぞれが異なる場合に役立ちます。

  • 認証コード:サーバー側アプリケーションで使用

  • 暗黙:モバイルアプリまたはWebアプリケーション(ユーザーのデバイスで実行されるアプリケーション)で使用されます

  • リソース所有者のパスワード資格情報:サービス自体が所有するような信頼できるアプリケーションで使用されます

  • クライアント資格情報:アプリケーションAPIアクセスで使用

次のセクションでは、グラントタイプ、そのユースケース、フローについて詳しく説明します。

付与タイプ:認証コード

*承認コード*付与タイプは、ソースコードが公開されていない_サーバー側アプリケーション_に最適化されており、_Client Secret_機密性を維持できるため、最も一般的に使用されます。 これはリダイレクトベースのフローです。つまり、アプリケーションは_user-agent_とやり取りできる必要があります(つまり、 ユーザーのウェブブラウザ)およびユーザーエージェントを介してルーティングされるAPI認証コードを受け取ります。

次に、認証コードフローについて説明します。

image:https://assets.digitalocean.com/articles/oauth/auth_code_flow.png [認証コードフロー]

ステップ1:認証コードリンク

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

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=&redirect_uri=&scope=

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

  • * https://cloud.digitalocean.com/v1/oauth/authorize*:API認証エンドポイント

  • * client_id = *:アプリケーションの_client ID_(APIがアプリケーションを識別する方法)

  • * redirect_uri = *:認証コードが付与された後、サービスはユーザーエージェントをリダイレクトします

  • * response_type = *:アプリケーションが認証コードの付与を要求していることを指定します

  • * scope = *:アプリケーションが要求しているアクセスのレベルを指定します

ステップ2:ユーザーがアプリケーションを承認する

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

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

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

ステップ3:アプリケーションは認証コードを受け取ります

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

https://dropletbook.com/callback?code=

ステップ4:アプリケーションリクエストアクセストークン

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

https://cloud.digitalocean.com/v1/oauth/token?client_id=&client_secret=&grant_type=authorization_code&code=&redirect_uri=

ステップ5:アプリケーションはアクセストークンを受け取ります

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

{"access_token":"","token_type":"bearer","expires_in":2592000,"refresh_token":"","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"[email protected]"}}

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

付与タイプ:暗黙的

  • implicit *付与タイプは、モバイルアプリとウェブアプリケーションに使用されます(つまり、 Webブラウザで実行されるアプリケーション)、_ client secret_の機密性は保証されていません。 暗黙的な付与タイプもリダイレクトベースのフローですが、アクセストークンはユーザーエージェントに与えられてアプリケーションに転送されるため、ユーザーやユーザーのデバイス上の他のアプリケーションに公開される可能性があります。 また、このフローはアプリケーションのIDを認証せず、リダイレクトURI(サービスに登録された)に依存してこの目的を果たします。

暗黙的な付与タイプは、更新トークンをサポートしていません。

暗黙的な許可フローは基本的に次のように機能します。ユーザーにアプリケーションの承認を求め、承認サーバーがアクセストークンをユーザーエージェントに渡し、ユーザーエージェントがそれをアプリケーションに渡します。 詳細に興味がある場合は、読んでください。

image:https://assets.digitalocean.com/articles/oauth/implicit_flow.png [暗黙的なフロー]

ステップ1:暗黙的な承認リンク

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

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=&redirect_uri=&scope=

ステップ2:ユーザーがアプリケーションを承認する

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

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

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

ステップ3:ユーザーエージェントはリダイレクトURIでアクセストークンを受信する

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

https://dropletbook.com/callback#token=

ステップ4:ユーザーエージェントがリダイレクトURIに従う

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

ステップ5:アプリケーションがアクセストークン抽出スクリプトを送信する

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

ステップ6:アプリケーションに渡されるアクセストークン

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

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

付与タイプ:リソース所有者のパスワード資格証明

*リソース所有者パスワード資格情報*付与タイプでは、ユーザーはサービス資格情報(ユーザー名とパスワード)をアプリケーションに直接提供し、アプリケーションは資格情報を使用してサービスからアクセストークンを取得します。 この許可タイプは、他のフローが実行可能でない場合にのみ許可サーバーで有効にする必要があります。 また、アプリケーションがユーザーに信頼されている場合にのみ使用する必要があります(例: サービスまたはユーザーのデスクトップOSが所有しています)。

パスワード認証情報フロー

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

https://oauth.example.com/token?grant_type=password&username=&password=&client_id=

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

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

付与タイプ:クライアント資格情報

*クライアントクレデンシャル*付与タイプは、アプリケーションが独自のサービスアカウントにアクセスする方法を提供します。 これが役立つ場合の例には、アプリケーションが登録された説明を更新したりURIをリダイレクトしたり、APIを介してサービスアカウントに保存されている他のデータにアクセスしたい場合があります。

クライアント資格情報フロー

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

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

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

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

アクセストークンの使用例

アプリケーションは、アクセストークンを取得すると、トークンの有効期限が切れるか取り消されるまで、トークンを使用して、アクセスの範囲に制限されたAPIを介してユーザーのアカウントにアクセスできます。

以下は、 `+ curl +`を使用したAPIリクエストの例です。 アクセストークンが含まれていることに注意してください。

curl -X POST -H "Authorization: Bearer ""https://api.digitalocean.com/v2/"

アクセストークンが有効であると仮定すると、APIはAPI仕様に従ってリクエストを処理します。 アクセストークンの有効期限が切れているか無効である場合、APIは「invalid_request」エラーを返します。

トークンフローの更新

アクセストークンの有効期限が切れた後、アクセストークンを使用してAPIからリクエストを行うと、「無効なトークンエラー」が発生します。 この時点で、元のアクセストークンが発行されたときに更新トークンが含まれていた場合、それを使用して承認サーバーから新しいアクセストークンを要求できます。

更新トークンを使用して新しいアクセストークンを取得するPOSTリクエストの例を次に示します。

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=&client_secret=&refresh_token=

結論

これで、このOAuth 2ガイドは終了です。 これで、OAuth 2の動作方法と、特定の承認フローをいつ使用する必要があるかを十分に把握できました。

OAuth 2の詳細については、次の貴重なリソースをご覧ください。

前の投稿:CentOS 7でPostgres、Nginx、Gunicornを使用してDjangoをセットアップする方法
次の投稿:Ubuntu 16.04でキャッシュまたは転送DNSサーバーとしてバインドを構成する方法