OAuthとGitHubログインの仕組みをざっくり理解する
これは「Happiness Chain Advent Calendar 2024」の 11 日目の記事です。
はじめに
現在、Django を使った Twitter クローンアプリを作成しており、その中で GitHub ログイン機能を実装する機会がありました。実装自体はできたものの、「OAuth」 と呼ばれる仕組みが何をしているのかよくわかりませんでした。そこで本記事では、OAuth の基本的な仕組みと GitHub ログインがどのように OAuth を活用しているかを紹介しようと思います。
OAuth って何？
こちらの記事がとてもわかりやすいので、まずは一度読むことをおすすめします！
OAuth（Open Authorization）とは、アプリやサービスがユーザーデータや機能に安全にアクセスできるようにする仕組みのことです。
例えば、以下のような場面で利用されています。
- Google アカウントを使って、他のアプリケーションにログインする
- 外部サービスから X の API を通じて、特定ユーザーのプロフィールやポストを取得する
- Slack と連携して、ユーザーが指定したチャンネルに対して通知を送信する
OAuth は『認可』のプロトコルである
ただし、OAuth はあくまで「認可（Authorization）」に焦点を当てたプロトコルです。
似た表現に「認証（Authentication）」がありますが、両者は異なる概念なので注意して下さい。
OAuth を使う上では、この違いを理解することが重要です。
- 認証（Authentication）:「あなたは誰ですか？」を確認するプロセス
- 認可（Authorization）:「このアプリがこのデータにアクセスするのを許可しますか？」を管理するプロセス
もし「認証」を取り扱う場合には、OpenID Connect という OAuth の拡張仕様が使用されます。
本記事では触れませんが、OpenID Connect を使うことで、ユーザーが誰であるかの確認 もできるため、OAuth と組み合わせて認証と認可を実現するケースもあるようです。
OAuth の仕組みについて
それでは OAuth の仕組みを具体的に見ていきましょう。
OAuth の構成要素
| 要素 | 説明 |
|---|---|
| リソースオーナー（=ユーザー） | 保護されたリソース（ユーザーデータ）を所有しているユーザー |
| リソースサーバー | 保護されたリソースを格納し、それを API で提供するサーバー |
| 認可サーバー | ユーザーのアクセス許可を管理するサーバー |
| クライアント（=アプリ） | リソースオーナー認可の下、リソースを要求するアプリ |
上記に加え、もう一つ「アクセストークン」という重要なものがあります。
これは「認可サーバーがアプリに発行する一時的な鍵」のようなもので、アプリはこれを利用してリソースサーバー上の保護されたリソースに安全にアクセスできるのです。
OAuth のフローについて
次に、OAuth の構成要素がどのような役割を果たしているか、実際のフローを見ていきます。
OAuth のフローは複数ありますが、今回は標準的なフローである「認可コードフロー（Authorization Code Flow）」を紹介します。
以下の 4 ステップで行われます。
-
アプリが認可リクエストを送信
- ユーザーがアプリを使って外部リソースへアクセスするために、
アプリは認可サーバーに対して、アクセス許可をもらうためのリクエストを送信します。
- ユーザーがアプリを使って外部リソースへアクセスするために、
-
ユーザーがアクセス許可を承認
- 認可サーバーは、ユーザーに対してアプリへのアクセス許可を要求します。
ユーザーがこれを承認すると、認可サーバーは「認証コード」をアプリに送信します。
- 認可サーバーは、ユーザーに対してアプリへのアクセス許可を要求します。
-
アプリがアクセストークンを取得
- アプリは認証コードを使って、認可サーバーからアクセストークンを受け取ります。
-
リソースサーバーへリクエストを送信
- アプリはアクセストークンを使ってリソースサーバーに API リクエストを送信し、必要なデータを取得します。
フローを図示すると、以下のようになります。
GitHub ログインと OAuth の関係
ここまでで OAuth のフローがなんとなく理解できたかと思います。
では GitHub ログインを例に、これに OAuth がどのように関わっているかを見ていきましょう。
ただその前に、こう疑問に思った方がいるかもしれません。
そういえば OAuth って『認可』のプロトコルだよね？？GitHub ログインって聞くと、
ユーザーが誰かを確認するステップだから、どちらかというと『認証』なのでは？？
こちらの方の記事でも同様なことが言及されていますが、GitHub ログインのどこに
OAuth の認可フローが取り入れられているのか、自分は最初イメージができませんでした。
これを理解するために、OAuth を構成する 4 つの要素に、実際の登場人物を当てはめてみます。
| 要素 | GitHub ログインにおける登場人物 |
|---|---|
| リソースオーナー | GitHub アカウントを所有するユーザー |
| リソースサーバー | GitHub（=GitHub のリソース取得する API） |
| 認可サーバー | GitHub（=GitHub の認可エンドポイント） |
| クライアント（=アプリ） | Twitter クローンアプリ（※GitHub ログインを実装するアプリ） |
特徴的なのは、GitHub がリソースサーバーと認可サーバーの両方の役割を担っていることです。これにより、アプリは認可フローを通じて取得したアクセストークンで、GitHub API から直接ユーザー情報を取得できます。そのため、アプリ側で認証処理を挟まなくても、取得したユーザー情報（例：ユーザー名やメールアドレス）をもとにログイン（認証）できるのです。
つまり、GitHub ログインは OAuth の「認可」フローを経由して、結果的に「認証」を実現しているのです。それを踏まえると、先程の疑問も解決するのではないでしょうか？
GitHub ログインは「認可」のプロセスを通っているのです。
以下は GitHub ログインのフロー図です。
おわりに
本記事では、OAuth の仕組みとそれが GitHub ログインにどのように関係しているかを、説明しました。OAuth 自体、理解しようとすると奥が深い領域ですが、全体像だけでも把握できれば、今後の開発に活かせる場面があると感じました。引き続き学習してみようと思います。
ここまで、読んでいただきありがとうございました！
参考サイト
Discussion