oauth2

GoogleのOAuth 2.0のチュートリアルを読んだのでメモ。

Basic steps

OAuthを使うアプリケーションが従う基本的なパターン

oauth 2.0 credentialをGoogle API Consoleから取得

Google API Consoleからcredentialを取得する。Credentialは

client ID
client secret

などから成る。アプリケーションのタイプによって、credentialの中身は異なる。

サーバーサイドアプリは、client secretを取得するが、クライアントサイドアプリは取得しない、など。

Google Authorization serverからアクセストークンを取得

アプリケーションが私的なデータにアクセスする前に、アクセスを許可するアクセストークンを取得する必要がある。 1つのトークンで、複数のAPIに対して様々な程度のアクセスを許可することが可能。「スコープ」パラメータによって、アクセス可能なリソースと許可される操作内容がコントロールされる。アクセストークンのリクエストには複数の方法があり、アプリケーションのタイプによって決まる。

アクセストークンのリクエストのプロセス中に、ユーザーはGoogleへのログインを求められることがある。ログイン後に、ユーザーは、アプリケーションに許可を与えるかどうかを選択することができる。このプロセスは、「user consent」と呼ばれる。

ユーザーが許可をした場合、Google Authorization Serverはアプリケーションにアクセストークン（もしくは、アクセストークンを取得するのに使えるコード）と許可されたスコープの一覧を返す。許可がされなかった場合、エラーが返る。

通常、スコープのリクエストは必要になるたびに、ちょっとずつ行ったほうが良い。

ユーザーによって許可されたスコープを試す

ユーザーによって許可されたスコープとアプリケーションが必要なスコープが一致しているかを確認する。

APIは、同一のスコープに対して複数の名前を与えている場合がある。

例：https://www.google.com/m8/feeds/ というスコープの許可を求めたときに https://www.googleapis.com/auth/contacts というスコープが返ってくる

アクセストークンをAPIに送る

アクセストークンは、HTTP Authorization request headerに入れて送る。URIパラメータに入れることも可能だが推奨されない。

アクセストークンは、複数回使い回せる

アクセストークンを更新する

アクセストークンには寿命がある。アクセストークンを寿命を超えて利用する場合、リフレッシュトークンをリクエストできる。

リフレッシュトークンは、十分セキュアな場所に保管し、有効な間は繰り返し使うべきである。リフレッシュトークンの個数は、(アプリケーション, ユーザー)の組み合わせに対してと、ユーザーに対して最大数が設定されており、その限界を超えてリフレッシュトークンがリクエストされると古いものが効力を失う。