フグ本OAuth2について(第三章)

3章

インプリシットグラントフロー

ユーザが認可要求を承認すると、即座にアプリケーションにアクセストークンが返される。

インプリシットグラントフローを使うべきケース

• 一時的なアクセスのみ

• ユーザが日常的にAPIプロバイダにログインしている時

• OAuthクライアントがブラウザで実行されている時(JSとかFlashとか)

• ぶらず兄対する信用度が高く、アクセストークンが信頼出来ないユーザやアプリケーションに流出する期限が限定されている時

インプリシットグラントフローの制限

このフローではリフレッシュトークンは使われない。認可サーバがアクセストークンの期限を短く設定している場合、アプリケーションは都度都度認可フローを実施しなければならない。
プロバイダの中には過去に同じスコープを承認したことがあれば、承認画面を表示しないプロバイダもある。

セキュリティ特性

アプリケーションが有効期限の長いリフレッシュトークンをサーバに保存することがないので、サーバに侵入されてもリスクが限定的。また、クライアントのアクセストークンを更新するにはAPiプロバイダの認可サーバにてユーザ認証を受ける必要があるので、アクセストークンが流出した際にOAuht実装に応じた有効期限で失効することが保証されている。
ただ、アクセストークンがユーザのwebブラウザに直接送られるので、認可コードフローに比べアカウンタビリティの面で劣る。また、サードパーティのアプリケーションいよって生成されたようみ見えているAPI呼び出しが実際はリソース所有者によって直接生成された可能性もある。

ユーザエクスペリエンス

ユーザエクスペリエンスはサーバサイドアプリケーションと全く同じ

アクセス権限の取り消し

インプリシットグラントフローでもサーバサイドwebアプリケーションと同様のフロー