OAuth 2.0 について実装しながら仕様を学んできました。

OAuth 2.0 の仕様理解はだいぶ深まったかなと思いつつ「結局、OAuthってなにがいいの？」という点について整理している情報があまりなかったので、OAuth 2.0 のメリットについてまとめてみました。

前提

説明するにあたり、例としてOAuth構成要素を下記とします。

OAuth 2.0 のメリット

クライアントへ限定的なリソースへのアクセス許可が可能な点がメリットの1つとなります。

例えば、カレンダーアプリをGoogleカレンダーと同期させる場合に「カレンダー取得API」へのアクセスだけを許可することができます。

そのため、カレンダーアプリが勝手にGoogleカレンダーの情報を更新したり、クリアしたりすることはできず、情報の取得のみができるように制限することができます。

クライアントへクレデンシャル情報（ID/PWなどの認証に必要な情報）を渡す必要がない点もメリットとなります。

例えば、カレンダーアプリへGoogleアカウントのID/PWを教えていないのに、カレンダーアプリはGoogleカレンダーへアクセスすることができます。

カレンダーアプリにクレデンシャル情報を渡す必要がある場合、もしカレンダーアプリが悪意のある攻撃者から不正アクセスされ自身のクレデンシャル情報を盗まれてしまうと攻撃者はその情報からGoogleアカウントへも不正アクセスができてしまいます。

OAuth 2.0 ではクライアントへリソースサーバーのクレデンシャル情報を渡さずに権限委譲が行えるため、クライアントが不正アクセスを受けたとしても、リソースサーバーへの被害を防ぐことができます。

クライアントへアクセス権を一時的に付与できる点もメリットとなります。

例えば、カレンダーアプリへカレンダー取得APIへのアクセスを許可した場合、カレンダーアプリはそれ以降ずっとGoogleカレンダーへアクセスし情報を取得することができるかというとそうではありません。

アクセス権には有効期限を設定することができ、その有効期限を迎えると、カレンダーアプリはGoogleカレンダーへのアクセス権が無効になります。

有効期限を迎えた場合は、再度リソースオーナーからアクセス許可をしてもらう必要があります。

クライアントへアクセスを許可した後、そのアクセス権の剥奪が容易に行えるのもメリットとなります。

例えば、カレンダーアプリへGoogleカレンダーへのアクセスを許可した後、やっぱり許可を取り下げたい、、となった場合は、いつでもアクセス権を剥奪することができます。

Googleアカウントの場合、管理画面でこのようにGoogleアカウントへアクセスを許可しているクライアントの一覧を確認することができ、ここからいつでも個別にアクセス権を削除することができます。

クライアントがリソースへのアクセスを行なう度にリソースオーナーによる認可操作の必要がない点もメリットの一つです。

例えば、カレンダーアプリにGoogleカレンダーへのアクセスを一度許可した後は、カレンダーアプリは一定期間自由なタイミングでGoogleカレンダー情報へアクセスすることができます。

カレンダーアプリがGoogleカレンダーの情報を毎ログインのたびに取得する仕様になっている場合、アプリへログインするたびに「カレンダーアプリがGoogleカレンダーへアクセスしようとしています、許可しますか？」なんて、確認してきたらめんどくさいですよね？

そのため、一度アクセス許可をしたクライアントについては、その後の一定期間は再度アクセスを認可する操作は必要ないようになっています。

以上です。