blueです。
今回X(旧Twitter)でOAuth（オーオウス）2.0を使って自動投稿できるようにしました。ただ今一つOAuth2.0について理解していなかったので自分なりにまとめました。
一般的な説明からXで使用しているKeyやトークンの説明もしているので参考になれば幸いです。
OAuthの仕組みをわかりやすく解説した動画です。実際の認可画面の紹介やハンズオンも含まれており、具体的な操作を学べます。この動画を見ることで、OAuthの基本だけでなく、Googleとの連携方法も理解できます。
技術者ではない方にOAuthを説明されてきた方の記事です。APIの基礎から、認可サーバーの説明もしてくださっています。この記事を読むとAPIを守る技術である「OAuth2.0」の概念がとてもよくわかるようになります。
OAuth2.0に関してわかりやすく、また詳しく書かれている書籍です。シリーズでいくつか本も出されているようです。私はまだ購入していませんがGoogleでのハンズオンをされているようなのでGoogle APIを使うタイミングになったら購入しようと思います。
認証と認可の違いを理解する
OAuth 2.0 を理解するためには、まず「認証」と「認可」を理解する必要があります。
| 概念 | 意味 | 例 |
|---|---|---|
| 認証（Authentication） | ユーザーが本人であることを確認するプロセス | Web サイトのログイン画面 |
| 認可（Authorization） | 認証されたクライアントにリソースへのアクセス権限を与えるプロセス | Twitter の OAuth 認証画面で「ツイートを読む」許可を与える |
図で表すと以下のようになります。
「認証」はユーザー自体がアクセスすること、「認可」はユーザーがクライアントアプリにアクセス権利を与えることになります。
難しそうに感じますが、実際に目にする画面を基にすると、わかりやすいと思います。
左が「認証」、右が「認可」になります。簡単に言うと「認証」は自分自身でアクセス、「認可」は自分のアプリにアクセス権を与えるイメージと考えてもらえばよいです。
認可サーバーやリソースサーバーについては後で説明します。
API Key 認証と OAuth認証の違いを理解する
他のアプリにアクセスする方法であればAPI Keyによる方法もあるじゃないかと思うかもしれません。
ただこの2つでは取得できる情報が異なっています。
| 比較項目 | OAuth 認証 | API Key 認証 |
| 用途 | ユーザーごとのデータ取得 | アプリごとのデータ取得 |
| セキュリティ | 高い（アクセストークン＋リフレッシュトークン） | 低い（API Key が漏れると全 API にアクセス可能） |
| 使う場面 | SNS やクラウドサービス | 天気 API、翻訳 API など |
API Keyで取得できる情報はユーザーごとによらない公的なものになります。天気情報などはアクセスするユーザーの情報は入っていません。
一方OAuthで取得できる情報はユーザーごとの情報です。Xでいうとツイート情報やアカウント情報です。
実際OAuthを使用しているサービスの例は以下のようなものがあります。SNSやクラウドサービスが並んでいることがわかります。
| サービス | 使用目的 |
|---|---|
| Google API | Google アカウントでログイン、Google Drive アクセス |
| Facebook API | Facebook アカウントでログイン、投稿の管理 |
| GitHub API | GitHub のリポジトリ管理、ユーザー認証 |
| Microsoft Graph API | Microsoft 365 のデータ管理（Outlook、OneDrive など） |
| Spotify API | ユーザーの音楽再生情報取得、プレイリスト管理 |
これらのサービスでは、OAuth 2.0 を使って安全にデータへアクセスし、ユーザーの権限を管理しています。
OAuth 2.0 の基本フローを理解する
OAuth 2.0 の認証フローは以下のようになります。
まずは 4 つの登場人物から説明します。
- ユーザー・・・データの所有者、つまりあなたです。自分のアプリにアクセスする権限があります。
- クライアントアプリ・・・ユーザーのデータを利用するアプリです。これはXではなく、第三者のアプリです。このアプリからXにアクセスするときにOAuthが関係してきます。
- 認可サーバー・・・認証とアクセストークンの発行を担当するサーバーです。Xではhttps://twitter.com/i/oauth2/authorizeになっています
- リソースサーバー・・・実際にデータを保持しているAPIです。ツイートを管理している場所はhttps://api.twitter.com/2/tweetsになります。
フローの説明は以下になります。
| ステップ | 説明 |
|---|---|
| １ 認可コードリクエスト | クライアントアプリが認可サーバーに「ユーザーのデータを使いたい」とリクエスト＋リダイレクトURLを添付 |
| ２ 認可リクエスト | 認可サーバーがユーザーに「アクセスを許可してよいか？」とリクエスト |
| 3 ユーザーが認可 | ユーザーが「このアプリに許可する」と承認 |
| 4 認可コード発行 | 認可サーバーが リダイレクトURLに認可コードを付けてリダイレクト。クライアントアプリが受け取る |
| 5 アクセストークンをリクエスト | クライアントアプリが認可コードを使ってアクセストークンをリクエスト |
| 6 アクセストークン発行 | アクセストークン（API用）とリフレッシュトークン（更新用）を発行 |
| 7 APIリクエスト | アクセストークンを使ってAPIにリクエスト |
| 8 アクセストークンの期限切れ | リフレッシュトークンを使って新しいアクセストークンを取得 |
この①、④、⑤、⑥がOAuthの仕組みになります。
X API で OAuth 2.0 による投稿が可能に
以前の X API では、OAuth 2.0 は読み取り専用（tweet.read など）に限定されていました。
しかし、TwitterがOAuth 2.0にPKCE(Proof Key for Code Exchange)を追加し、ツイートの自動投稿などの書き込み（write）が可能になりました。
詳細は、Twitterの公式開発者ブログの以下の記事などで確認できます。
Twitter Developer Blog: Announcing OAuth 2.0 Authorization Code with PKCE
X API を利用した OAuth 2.0 のフロー
XでのOAuth 2.0 の認証フローは以下のようになります。
テーブルにまとめると以下のようになります。
| ステップ | 説明 | 使用する Key/トークン |
|---|---|---|
| 1 認可コードリクエスト | クライアントアプリが認可サーバーに「ユーザーのデータを使いたい」とリクエスト。リダイレクト URL を添付 | クライアント ID, リダイレクト URL |
| 2 認可リクエスト | 認可サーバーがユーザーに「アクセスを許可してよいか？」とリクエスト | なし |
| 3 ユーザーが認可 | ユーザーが「このアプリに許可する」と承認 | なし |
| 4 認可コード発行 | 認可サーバーがリダイレクト URL に認可コードを付けてリダイレクト。クライアントアプリが受け取る | 認可コード |
| 5 アクセストークンをリクエスト | クライアントアプリが認可コードを使ってアクセストークンをリクエスト | 認可コード, クライアントID, クライアントシークレット |
| 6 アクセストークン発行 | アクセストークンとリフレッシュトークン（更新用）を発行 | アクセストークン, リフレッシュトークン |
| 7 API リクエスト | アクセストークンを使って X API にリクエスト | アクセストークン |
| 8 アクセストークンの期限切れ | リフレッシュトークンを使って新しいアクセストークンを取得 | リフレッシュトークン |
流れをまとめると
- OAuth2.0では認可コード発行→アクセストークン発行→APIアクセスの流れになる
- クライアントアプリはアクセストークンを得て初めてAPIにアクセスできるようになる
- アクセストークンの期限が切れたらリフレッシュトークンを使うことで更新ができる
になります。
まとめ
今回OAuth2.0に関する記事を書きました。OAuth2.0についてまとめると
- ユーザー情報へのアクセスはAPIだけではなくOAuthの理解が必要
- OAuth2.0ではクライアントアプリが認可コード、アクセストークンを取得している
- X APIではOAuth2.0にPKCEを追加することでread, write対応可能としている
OAuthの理解に少しでも役に立つと幸いです。
APIを理解できると自分で作るアプリに組み込むことができます。
さらに生成AIのAPIと組み合わせることで無限大の可能性が広がります。
私の書いている書籍なども参考ください。
コメント