どのソーシャルプラットフォームも独自のOAuth実装を持っており、共通しているのはおおよその形だけで、それ以外は一致しません。ここで引き受けることになるものと、省略できるものを見ていきます。
プラットフォームごとに異なる点
スコープ。 名前も、粒度も、要件も異なります。要求しすぎるとアプリの審査で却下されます。要求が足りないと、機能が静かに動かなくなります。
トークンの有効期限。 長く有効なトークンもあります。数週間で失効するものもあります。知っておくべき別の呼び出しを通じて、より長期のトークンと交換できるものもあります。
更新の挙動。 リフレッシュトークンを発行するプラットフォームもあれば、再認可を求めるものもあります。毎回リフレッシュトークンをローテーションするため、古いものを保存していると次の更新が壊れるものもあります。
審査。 いくつかのプラットフォームは、アプリを審査するまで公開用スコープを付与しません。プライバシーポリシー、デモ動画、そして待機を伴うことがあります。これは自分でコントロールできないカレンダー上の時間であり、拒否されることもあります。
アカウントモデル。 個人プロフィール、ページ、ビジネスアカウント、チャンネルは、権限の異なる別のオブジェクトです。トークンを取得することと、実際にどのアカウントに投稿できるかを知ることは同じではありません。
実際に壊れる部分：更新
初回のフローではありません。初回のフローは1日の作業で終わります。
本番環境で壊れるのは更新処理で、しかも静かに壊れます。
- トークンが失効し、3日前にリフレッシュのジョブが失敗していた
- 目に見えるエラーは何も出ない。なぜなら、今まで公開を試みていなかったから
- 予約投稿が失敗する
- ユーザーがあなたより先に気づく
まともな実装には、定期的なリフレッシュジョブ、リフレッシュ失敗の監視、接続が壊れていることを示す仕組み、UI上の再接続プロンプトが必要です。これはOAuthフロー自体より多くの作業で、見積もりから抜け落ちがちな部分です。
自前で実装する場合
最初からやっておく価値のあること。
トークンは暗号化して保存し、絶対にログに出さないこと。それらは他人のアカウントへの資格情報です。
有効期限を保存し、失敗してからではなく、その前に更新すること。
ローテーションに対応する。 プラットフォームがリフレッシュトークンをローテーションするなら、使う前に新しいものを書き込むこと。使った後ではありません。
接続が壊れた状態を、実際の状態としてモデル化する。 キャッチするエラーではなく、ユーザーが目にして直せる状態にすること。
再認可を想定しておく。 権限の変更やポリシー更新により、何をしていてもユーザーが時々再接続を必要とします。
その大部分を避ける
公開機能があなたの製品そのものではなく製品の一機能なら、代替案はプラットフォームのOAuthを他社に任せる1つの連携だけにすることです。
2つの認証モデルがあり、正しいものを選ぶことが重要です。
APIキー。 自分自身のアカウントに対して操作する場合。サーバー間通信で、ユーザーの同意フローがなく、動くもののうち最もシンプルです。
OAuth。 ユーザーに代わって操作する場合。ユーザーがあなたのアプリを承認し、あなたは自社製品に資格情報を貼り付けさせる代わりに、ユーザーが選んだワークスペースに紐づいたスコープ付きトークンを受け取ります。
あなたの製品がマルチユーザーなら、最初からOAuthを使いましょう。ユーザーにAPIキーを貼り付けさせるのは、後でやり直すことになる移行であり、望ましくない習慣をユーザーに教えることになります。
BulkPublishのOAuthの仕組み
- 認可エンドポイント：
https://app.bulkpublish.com/oauth/authorize - トークンエンドポイント：
https://app.bulkpublish.com/api/oauth/token - すべてのクライアントでPKCE（S256）が必須
scopeは必須で、暗黙の既定値はなし- 認可コードは一度限りで、リフレッシュトークンはローテーションする
- トークンは
Bearer bpat_...として渡される
スコープは細かく分かれています。posts:read、posts:write、media:read、media:write、analytics:read、channels:read、またはfullです。
意図的な境界として知っておく価値があるのは次の点です。OAuthトークンが届く範囲は、投稿、スケジュール、ラベル、メディア、アナリティクス、クォータ使用量、読み取り専用のチャンネルデータまでで、それ以外にはアクセスできません。アカウント管理、つまりチーム、組織、請求、クレジット購入、APIキー、OAuthアプリ管理は、fullを含むどのOAuthトークンでも403を返します。これらの操作はユーザーがあなたのアプリの接続を解除した後も残り続けるため、代わりにAPIキーが必要です。
これは、本番環境で403に出会ってから知るのではなく、早い段階で設計しておく価値のある制限です。
まとめ
OAuthフローはプラットフォームあたり1日です。トークンの更新は永遠に続き、しかも静かに失敗します。だからこそ実際に痛手となる部分です。公開機能があなたの製品そのものではなく一機能なら、プロバイダーとの1つの連携で、この15回分をなくせます。他人のアカウントが関わる時点で、貼り付け式のAPIキーではなくOAuthを使いましょう。