５章
クライアントクレデンシャルフロー
クライアント自身がデータを所有していて、リソース所有者からのアクセス譲渡が不要な場合に使われるフロー
このフローはOAuht1.0の2-leggedフローと同じような事例に適合するフロー。
クライアントクレデンシャルフローを使いべきケース
リソース所有者がアプリケーションに対して通常OAuthフロー以外の手段で自分のリソースにアクセス権限を与えている場合。
クライアント認証の方法
「クライアントが認可サーバによって適切に認証できるとこ」「認証クレデンシャルの機密性が守られていること」の２点が重要。クライアントが認証を受けるには、認可サーバにclient_idとclient_secretを送ればいいが、アクセストークン要求時にPOSTパラメータとして送る方法とHTTP Basic認証のAuthenticationヘッダを使って送る方法がある。その他にも 公開鍵/秘密鍵のペアを使う方法やSSL/TLSクライアント認証による方法などもある。
セキュリティ特性
クライアントクレデンシャルフローでは一組のクライアントクレデンシャルで大量のデータにアクセスできる。一組のクライアントクレデンシャルからアクセスできるデータ量が大きくなるほど、漏洩のリスクは高まる。なので、クライアントの認証用のクレデンシャルは漏洩しないように管理することが重要。
認証ステップ
ex.facebookのApp Login機能
ステップ１ アプリケーションのクレデンシャルをアクセストークンへ交換
アプリケーションから認可サーバへアクセストークンリクエストを送る。このリクエストにはクライアントクレデンシャルによる認証が必要。
POSTパラメータに必要なもの
grant_type
client_credentialsを指定client_id
アプリケーションを登録した時に割り当てたれた値cliet_secret
アプリケーション登録時に割り当てられた値
クライアントクレデンシャルにおる認証が終わると、クライアントにアクセストークンが返される。Facebookでは、access_tokenがURLエンコードされ、レスポンスボディに含まれた形で返される。
ステップ２ API呼び出し
クライアントクレデンシャルフローで発行されるOAuthアクセストークンは、その他のフローで発行されるものと同じなので、使用方法も同じ。APIのプロバイダのサポート状況にあわせて、HTTP Authoraizationヘッダ、またはクエリパラメータの値としてアクセストークンを渡す。
アクセストークンの有効期限
クライアントクレデンシャルでは、有効期限の長いアクセストークンが発行される。仕様ではリフレッシュトークンの発行はサポートされていないなので、有効期限が切れた場合は新しくアクセストークンを要求し直す。