https://developers.facebook.com/roadmap/offline-access-removal/を読むたびに、以前よりも混乱します。シナリオ 3 と 4 (サーバー側アプリとクライアント側アプリ) のいくつかの項目について、説明を求めています。
サーバー側アプリの場合、「そのユーザーの有効な 60 日間の access_token が残っている間に呼び出しが行われた場合、この 2 番目の呼び出しから返された access_token は同じであるか変更されている可能性がありますが、いずれの場合も有効期限は時間は新たな 60 日になります。」
- ここでいう「呼びかけ」とは？
- 最初の OAuth フローで行われるアクセス トークンの認証コードの交換と同じですか?
- それとも、トークンを 60 日に更新するために、クライアント側のセクションで説明されているエンドポイント呼び出しですか?
- 前者の場合、トークンを更新しようとすると、認証コードはどこから来るのでしょうか?
- 元のコールバックからの認証コードと同じですか、それとも認証フローをもう一度実行する必要がありますか?
要するに、サーバー側のアプリは 60 日間のトークンの寿命を更新し続けることができますか? もしそうなら、どのように?
クライアント側の使用に関して、ドキュメントは、クライアントがアプリケーションのクライアント ID とクライアント シークレットを渡してエンドポイント呼び出しを行う必要があることを示しています。
- 「クライアント側」の私の解釈は間違っているかもしれませんが、Web ブラウザーで実行される JavaScript ベースのクライアントの観点から考えています。
- それがFacebookがここで念頭に置いていることである場合、JavaScriptコードはクライアントシークレットについて本当に知っているべきでしょうか? （クライアントに送信された場合、それはあまり秘密にはなりません。）
それでも、60 日間のトークンの寿命を延ばすことはできず、新しい 2 時間のトークンを最初に取得して、60 日間のトークンを取得するために使用する必要があることを示しています。これはドキュメントのクライアント側の部分にありますが、この規則はサーバー側の 60 日間トークンにも適用されますか? そうでない場合は、もう一度質問します。サーバー側で 60 日間のトークンの寿命を更新するにはどうすればよいですか?
最後に、しばらくの間私の頭に焼き付いていた疑問: なぜ Facebook はこの戦略を採用し、OAuth 2 仕様 (Facebook が定義を支援している仕様) で定義されている更新トークンを採用しなかったのか???
編集:ドキュメントをもう一度読み直した後のさらなる考え/質問:
冒頭には、「ユーザーがアプリを再起動するたびに更新できる有効期限が長い」と書かれています。私の最初の仮定は、それを更新する方法は、ドキュメントの後半でエンドポイントを呼び出すことであるということです。ただし、エンドポイントが「クライアント側」の見出しの下に記述されているという事実は別として、「エンドポイントは、有効期間が短いユーザー access_tokens を拡張するためにのみ使用できることに注意してください。エンドポイントは、有効期限を変更または延長することなく、単に同じ access_token をユーザーに返します。」(「長い間」のタイプミスは、FB 自身のドキュメントからのものです。)
さて、そのエンドポイントを使用して有効期限を更新できない場合 (そして、そのエンドポイントで有効期間の長いトークンを更新しようとする私自身の試みがこれを証明しています)、毎回有効期限の長いトークンの有効期限を更新するにはどうすればよいですか?彼らは私のアプリにアクセスしますか？
これがどのように機能するかを理解している人はいませんか？