モチベーション

個人開発でYoutube Data APIを利用したかったので、ドキュメント読みOAuth2.0を雰囲気で理解しました。

サービスのコア機能であることや、ライブラリの利用方法だけ理解し実装することはユーザーの個人情報流出リスクが高いと考え、正しい知識を身に付けようと思いました。¹

書籍での学び

Using OAuth 2.0 to Access Google APIsのシーケンス図では、Google Serviceとして認可サーバーとリソースサーバーがまとめられています。書籍にて認可サーバーとリソースサーバーが紹介されており、認識のズレがなくなりました

認可リクエスト時に、response_typeを必須パラメータとして与える必要があります。

response_typeには、codeとtokenの選択肢がありますが、両者の違いが不明確でした。

5章の認可コードグラントとインプリシットグランドの説明を読むことで、response_typeがcodeの時は認可コードグラント、tokenの時はインプリシットグランドであることがわかりました。

インプリシットグランドは、認可リクエストを行うとアクセストークンを取得することができるのが特徴です。²

そのため、セキュリティの問題でインプリシットグランドが非推奨であることがわかりました。

個人開発のサービスでは、response_type=codeにしておけばいいことがわかりました。

MDNにも、以下のような記載があります。

# より後の部分はフラグメント識別としても知られており、要求でサーバーには送信されないことは注目に値します。

知見でした。

GoogleのOAuthドキュメントを読むまでは、OAuthは認証の仕組みであると思っていました。

なぜ、このような勘違いをしていたか明らかでなかったのですが付録Aを読んで腑に落ちました。

Rubyのライブラリであるomniauth-google-oauth2でしかOAuthという存在を知らなかったのでOAuthは認証の仕組みであると勘違いしていた。