Credentials)を用いて雰囲気で実装していました。2.0について改めて調べ直したのでそのメモです。仕組みを理解し、裏側で何が起こっているのかをイメージした上で実装できるようにすることが今回の目的だったため、個々の技術は一部簡略化して記載しています。TL;DR認証・認可では誰がアクセスしてきていて、どのリソースに対してアクセスする権限があるのか確認している。OAuth2.0では、最終的にアクセストークンを鍵として扱っているだけ。「誰が」アクセスしてきているのかを確認したい。紐づいて管理されているリソースにはアクセスできない状態。仮に、Twitterで認証は行えたが認可は行われていない状態ならば、パブリックなツイートを見ることはできるが、鍵アカのツイートや自分のツイート、DMなどは見ることができない状態。認可ではアクセスしてきた人がどのリソースに対しての権限を持っているのかを確認したい。通常、認証で本人確認が完了したのちに認可が行われ、ユーザーがリソースにアクセスする権限を持っているかどうかを確認する。先ほどのTwitterの例だと、認証後に認可を行いリソースに対するアクセス権を確認することで、自分のDMやフォローしている鍵アカのツイートは見ることができるようになるが、フォローできていない鍵アカのツイートや他人のDMは見ることができない。おまけ:HTTPステータスでの使い分けHTTPステータスで400系エラーコードは不正なリクエストに対するエラーコードですが、その中でも認証認可は使い分けがされています。有効な認証資格が不足していることによりリクエストが適用されないことを示すクライアントエラーのレスポンスコードです。クライアントエラーレスポンスコードは、サーバーがリクエストを理解したものの、認証が拒否されたことを示します。[401](https://developer.mozilla.org/ja/docs/Web/HTTP/Status/401)に似ていますが、この場合は再認証しても結果は変わりません。アクセスは恒久的に禁止されており、リソースにアクセスする権限が不足しているなど、アプリケーションのロジックに結びついたものです。MDN*MDNでは「認証が拒否されたことを示します。」と書かれているので、認可エラーではなく認証エラーじゃないか。Forbiddenを認可エラー時に使用すると捉えて問題なさそうです。認証認可は別物である。いうことがここまででわかりました。世の中にはどんな認証方式があるのか見て行きたいと思います。Basic認証ユーザーIDとパスワードの組みをBase64でエンコードしてAuthorizationヘッダーに詰めてサーバーに送信することで認証を行う方式です。shgnkn:mypassword実装が楽なので活用されることが多いようですが、ユーザーIDとパスワードの組みをBase64でエンコードしているだけなので通信が傍受されてしまった場合ユーザーIDとパスワードがダダ漏れです。/TLS(HTTPS)で通信を暗号化して活用します。Digest認証Basic認証と基本的には同じで、AuthorizationヘッダーにユーザーIDとパスワードの組みを詰めてサーバーに送信することで認証を行います。Basic認証と異なる点としては、Authorizationヘッダーに情報を詰める前に、最初のレスポンスでサーバーから返ってきたランダムな文字列とクライアントで生成したランダムな文字列、ユーザーID、パスワードをハッシュ関数で暗号化してから詰めるので、セキュリティが向上しています。平文がそのまま送られてしまうBasic認証よりはセキュアになっています。最新のブラウザはSHA-256に対応していますが、古いブラウザだとMD5にしか対応していない場合もあるのでその場合には注意が必要です。(MD5は既に脆弱性が見つかっているため非推奨です。保護されたリソースにアクセスする際にBearerトークンを用いる方式です。2.0の学習をメインで行ったので、詳細は後ほど記載します。今までBasic認証、Digest認証、Bearer認証は触れたことがあったのですが、今回認証方式にはどんなものがあるのだろうと調べた際に思ったよりも色々な種類があって驚きました。詳細は触れませんが、IANAに記載されていた認証方式を列挙しておきます。Connect認証方式には上で挙げたように様々な方式がありますが、認証の機能を自前で実装するのは大変です。そこで、Googleアカウント、Twitterアカウント、Facebookアカウントなど外部サービスのアカウントを用いて認証を外部に委託するといったことがよく行われます。Connectと言われるもので、auth0などのベンダーによって機能が提供されています。Connectの仕様を深く調べることはできていないので、詳細は省きます。2.0認証方式にどのようなものがあるのかは1つ前のパートで見てきました。2.0は認証方式を定めたプロトコルではなく、「アクセストークンの要求とその応答」を標準化したプロトコルです。アクセストークンを発行する認可サーバーを自前で実装するのが大変なため、AuthleteやAuth0といったサービスを利用することが多いかと思います。Serverにアクセスするまでの流れは以下のようになります。access-tokenを詰めてリクエストすることでリソースへのアクセスが可能になります。Secretを用いて認証を行ったりといったフローがあったりするのですが、それらはOAuth2.0とは別のRFCで定義されたものなので今回の図からは省きました。Serverにアクセスするフローはわかりました。Driveをマウントしようとした際の挙動を用いて流れを追ってみます。実行環境IncognitoモードでColaboratoryを開きます。その状態で、何らかのコードを実行しようとするとGoogleへのログインを求められるので、ログインします。Colaboratoryの実行環境)にアクセスするのかを確認する、認証を行っています。ログイン後は、Notebookの編集が一度全てリセットされるので、そこから以下コードを実行して行きます。Drive内にあるリソースに対してColaboratoryからアクセスすることができるようにしてみます。Drive内にあるリソースを許可するということは、自分のアカウントでリソースに対してアクセスする権限があるのかを確認する「認可」を行ういくことになります。ここでOAuth2.0の仕組みが活躍していきます。認可フローまずはアクセスを許可するか確認のモーダルが出てきます。次にどのアカウントのリソースに対してのアクセスを許可するか選択します。今回はアカウントが一つしか写っていませんが、複数アカウントでログインしている状況だと複数アカウントが選択肢として表示されるはずです。最後に、今回Colaboratoryにアクセスを許可するスコープの確認画面が出ます。ここで、どのリソースに対するアクセス権をColaboratoryに付与するか確認をとっています。Drive上のリソースにアクセス可能となります。Driveにアクセスするリクエストが送られる際には、ここで取得したアクセストークンがAuthorizationヘッダーに詰められてリクエストされることになります。withGatsby。