API連携に必須のOAuth認証とは？クライアントID・シークレットをLINEとXの実例で解説

自分はLINE公式アカウントの自動化とか、Xの投稿自動化とか、いろんなAPIを日常的に触ってる。で、最初に必ずつまずくのが「クライアントIDって何？」「シークレットって？」「OAuthって何のこと？」という部分。

ちなみにOAuthは「オーオース」と読む。「オース」でも通じる。最初に読み方がわからないと検索すらできないので、ここで覚えておいてほしい。

意味は「Open Authorization（オープン・オーソライゼーション）」の略。Authorizationは「認可」、つまり「何をしていいか許可する」ということ。Openは特定の企業に縛られないオープンな規格という意味で、だからLINEもXもGoogleも同じOAuthの仕様に乗っかれる。

ドキュメントを読んでもカタカナと英語の嵐で、正直最初は意味がわからなかった。でも一回理解すると全部同じパターンだとわかる。今日はこれをLINEとXの実例を使って、できるだけシンプルに説明してみる。

APIを使うときに必ず出てくる「認証」って何？

すごくシンプルに言うと「あなたは誰ですか？本当に使っていい人ですか？」を確認する仕組み。

たとえばマンションのオートロックを想像してみてほしい。住人なら鍵を持ってるから入れる。でも鍵を持ってない人は入れない。APIの認証もこれとまったく同じ。

LINEのサーバーにメッセージ送信のリクエストを投げるとき、LINEからすると「このリクエスト、本当に正規のアプリから来てるの？」と確認したい。知らない誰かが勝手にメッセージを送れたら大問題だから。

だから認証なしで使えるAPIはほとんどない。天気情報みたいな誰でも見ていいデータでも、無制限にアクセスされたらサーバーがパンクするから、最低限「誰が使ってるか」は把握したい。それが認証の目的。

クライアントIDとクライアントシークレットの正体

銀行口座で考えるとわかりやすい。

クライアントIDは「あなたのアプリの識別番号」。これは公開されても問題ない。LINEのログインボタンを設置したWebサイトのソースコードを見ると、クライアントIDが書いてあることもある。口座番号を知られただけではお金は引き出せないのと同じ。

一方クライアントシークレットは「あなたのアプリだけが知っている秘密の鍵」。これが漏れると、他人があなたのアプリになりすましてAPIを使えてしまう。暗証番号が漏れたら口座から勝手に引き出されるのと同じ。

ちなみにサービスによって呼び方が違うから混乱しがちだけど、中身は同じ。

名前が違うだけで役割はまったく同じ。「IDは見せてOK、シークレットは絶対に隠す」。これだけ覚えておけばどのサービスでも迷わない。

OAuth認証ってそもそも何を解決するの？

OAuthが登場する前の世界を想像してみてほしい。

たとえば「XのフォロワーをCSVでダウンロードできるWebサービス」があったとする。OAuth以前は、そのサービスにXのユーザー名とパスワードを直接入力する必要があった。

これ、よく考えるとめちゃくちゃ怖い。そのサービスが悪意を持っていたら、パスワードを使ってアカウントを乗っ取れてしまう。

そこで生まれたのがOAuth。ホテルの鍵にたとえるとわかりやすい。

OAuthの仕組みでは、ユーザーのパスワードをアプリに渡す代わりに「アクセストークン」という一時的な許可証を発行する。このトークンには「何ができるか」「いつまで有効か」が書かれていて、必要最小限の権限しかない。

つまりマスターキーを渡す代わりに、カードキーを渡す。カードキーなら特定の部屋しか開けられないし、チェックアウトしたら無効になる。パスワードを直接渡すより圧倒的に安全。

OAuth 1.0と2.0の違いをざっくり理解する

結論から言うと、今から覚えるなら2.0だけで大丈夫。1.0はほぼ使われなくなってる。でも違いを知っておくとXのAPI周りの話がスッキリするから、ざっくり説明する。

OAuth 1.0（正確には1.0a）

2007年に登場した初代OAuth。最大の特徴は「署名（シグネチャ）」の仕組み。APIリクエストのたびに、リクエストの内容とシークレットを組み合わせて暗号的な署名を作る。サーバー側はその署名を検証して「本物のリクエストだ」と判断する。

セキュリティは堅いけど、署名の計算がとにかく面倒。タイムスタンプやナンスという使い捨ての乱数も必要で、実装するエンジニアにとってはかなり苦痛だった。

OAuth 2.0

2012年に登場した後継バージョン。署名の仕組みを廃止して、代わりにHTTPS（暗号化通信）を前提にした。アクセストークンをリクエストのヘッダーにそのまま載せるだけ。

今新しく作られるサービスでOAuth 1.0を採用するものはまずない。XもAPIのv2からOAuth 2.0に対応した。だから実務的には「OAuthといえば2.0」と思って問題ない。

【実例①】LINE Messaging APIの認証の仕組み

LINE Messaging APIは、LINE公式アカウントからメッセージを送ったり、ユーザーからのメッセージを受け取ったりするためのAPI。これはOAuth 2.0ベース。

LINE Developersコンソールでチャネルを作ると、以下の2つが発行される。

ここでMessaging APIがちょっと特殊なのは、実際のAPIリクエストではこの2つを直接使うのではなく「チャネルアクセストークン」を使うということ。

流れはこう。

いいところに気づいた。Messaging APIの場合、ユーザーのログインを挟まない。アプリ（Bot）自身の認証だけで完結する。これはOAuth 2.0の中でも「クライアントクレデンシャル」と呼ばれるフローで、サーバー対サーバーの通信で使われるパターン。

ユーザーの許可を得る必要がないから、フローとしては一番シンプル。チャネルID・チャネルシークレットを使ってトークンを取得し、あとはそのトークンで全部やる。

【実例②】LINEログインの認証フロー

「LINEでログイン」ボタンを押してWebサービスにログインする、あの仕組み。これもLINE Developersで「LINEログイン」チャネルを作ると、チャネルIDとチャネルシークレットが発行される。

でもMessaging APIとは流れが全然違う。なぜならLINEログインでは「ユーザー本人の許可」が必要だから。

具体的な流れはこう。

セキュリティのため。認可コードはブラウザのURLに表示される（リダイレクトURLのパラメータに入る）から、万が一誰かに見られる可能性がある。でも認可コードだけではAPIは使えない。

認可コードをアクセストークンに交換するとき、チャネルシークレットが必要になる。これはサーバー側にしか置いてないから、認可コードが漏れてもシークレットを持ってない人はトークンを取得できない。二重のロックがかかってるイメージ。

これがOAuth 2.0の「認可コードフロー」と呼ばれるもので、LINEログインだけでなく、GoogleログインやFacebookログインもまったく同じ仕組み。一度覚えれば全部わかる。

【実例③】X（Twitter）APIの認証

XのAPIは歴史的に面白い変遷をたどってきた。

もともとTwitter API v1.1はOAuth 1.0aを使っていた。つまり署名ベース。APIを叩くたびにConsumer Key、Consumer Secret、Access Token、Access Token Secretの4つを使って署名を計算する必要があった。

そう、ここがOAuth 1.0のややこしいところ。整理するとこう。

OAuth 2.0ならアクセストークン1つをヘッダーに載せるだけなのに、1.0aではこの4つを組み合わせて毎回署名を作る。タイムスタンプとナンス（ランダム文字列）も加えて、特定のルールで文字列を並べ替えて、HMAC-SHA1で暗号化して…。正直言って手作業でやるのは苦行だった。

そしてAPI v2からはOAuth 2.0（PKCE付き）にも対応した。PKCEは「Proof Key for Code Exchange」の略で、認可コードフローをモバイルアプリやSPA（シングルページアプリケーション）でも安全に使えるようにした拡張仕様。

今のX APIでは用途によって認証方式を選べる。

実務的には、自分のBotアカウントでツイートを自動投稿するだけならOAuth 2.0のApp Onlyで十分。他のユーザーの代理操作が必要なケースだけ、ユーザー認証フローを使う。

まとめ：結局覚えておくべきこと

API連携を初めてやるときは「認証」が最大のハードルに感じるけど、結局やってることは毎回同じ。IDとシークレットを登録して、トークンを取得して、そのトークンでAPIを叩く。この基本パターンさえ押さえれば、新しいサービスのAPIに触るときも「またこのパターンか」と思えるようになる。