読むべき人
OAuth？なんかあれでしょ？
認証の時の、。
なんかフロー的な、あれでしょ？
という人。
OAuthとはずばり何
サービス間連携する時のフレームワークのようなものです。
そう、フレームワークのようなものなのです。
OAuthを理解しようとするとやたら詳しく細かく説明してある図ばっかりが検索に引っかかって、小難しい言葉の羅列に理解する気を削がれた人は多いのではないかと思います。
まずはこのことを頭に叩き込んでください。
OAuthは認証処理をする上での「こんな感じでやることにしようぜ」っていうガイドラインに過ぎないのです。
どんな時に使うものなの？
本質は簡単です。
Googleのスプレッドシートに保存してある情報を、別のアプリケーションが利用したいとします。
普通ならそのアプリケーションがユーザーのID・パスワードを把握すれば簡単に実現できると思いますよね。
でもID・パスワードを把握するってことは何処の馬の骨かもわからん謎のアプリが、
やろうと思えば
GoogleDriveに保存してある大事な資料を全て消したのち、
密かに想いを寄せていた取引先のかわいい女性にGmailで勝手に愛の告白をし、
YouTubeで知りもしないYouTuberのライブ配信に巨額のスパチャを送ることだってできてしまうわけです。
それはいかんということで、そのアプリケーションにスプレッドシートの閲覧の権限のみを渡したい！
そんな願いを叶えるのがOAuthの仕組みです。
ちまたの図には何やら難しい単語が羅列されていますが、今回は概要の概要を理解するため、テクニカルな用語は最小限で説明します。
① アプリケーション「スプレッドシートにアクセスさせてくださーい！という要求」
② Googleの認可サーバー「アプリケーションがあんたのスプレッドシートのデータ使いたいって言ってるぞ」
③ ユーザー「じゃあIDとパスワード渡しとくわ」
④ Googleの認可サーバー「使っていいらしいよ。でもお前のことそこまで信用できないからスプレッドシートだけ見れるための許可証だけ渡しておくわ。」
⑤ アプリケーション「スプレッドシートさーん、データ見せてー！あ、IDとパスワードはないけど専用の許可証はあるっすー。」
と言った流れになっています。
何がそんなにいいの？
上の流れでなんとなくは伝わったと思いますが、つまりは
・サードパーティのアプリケーションにユーザーのIDとパスワードが伝わっていない
・サードパーティのアプリケーションはユーザーのIDとパスワードを保存していない
・許可証となる専用のアクセストークンを発行することで権限を最小限に絞ることができる
ってわけです。
こうすることでサードパーティのアプリが暴走しようとしてもせいぜいスプレッドシートのデータをばら撒くくらいしかできないわけです。