REST経由でAPIにアクセスすることは、おそらくないということに留意してください。本格的なアプリケーションの場合は、好みの言語で書かれたライブラリを使用する方がよいでしょう。変更すれば、ユーザはリクエストしたスコープを編集できます。すると、アプリケーションに対して元々リクエストしたよりも少ないアクセスだけを許可できます。トークンでリクエストを行う前に、ユーザからトークンに付与されたスコープを確認してください。Appのスコープ」を参照してください。付与されたスコープは、トークンの交換による応答の一部として返されます。アプリケーションが他のスコープを要求していれば、それらについても確認します。スコープ間には階層的な関係があるため、必要なスコープのうち最も下位レベルのものが付与されたか確認する必要があります。スコープのみが付与されていることがあり得ます。その場合、アプリケーションが要求したスコープは付与されていないかもしれませんが、付与されたスコープでも十分でしょう。要求を行う前にだけスコープを確認するのでは不十分です。いうのは、確認時と実際の要求時の間に、ユーザーがスコープを変更する可能性があるからです。ステータスになって失敗したり、情報の別のサブセットが返されたりする可能性があります。ヘッダーも含まれています。このヘッダーには、要求を行うために使用されたトークンのスコープのリストが含まれています。トークンの有効性を確認するためのエンドポイントが用意されています。この情報を使用してトークンのスコープ内での変更を検出し、利用可能なアプリケーション機能における変更をユーザーに通知します。トークンで、ログイン済みユーザーとして認証の要求を行うことができます。auth_resultこの結果を使って、やりたいことができます。ページにアクセスするたびに、ユーザーにアプリケーションへのログインを求めるとしたら、それは非常に悪いモデルです。移動してみてください。エラーになるでしょう。このアプリケーションにアクセスできるとしたらどうでしょうか。上記に上げたサーバはかなり単純なものです。インテリジェントな認証を利用する目的で、トークンを保存するためにセッションを使用するように切り替えます。これにより、認証はユーザーに意識されないものになります。セッション内のスコープを永続的にしているため、そのスコープを確認した後にユーザーが更新した場合や、トークンを取り消した場合に対処する必要があります。呼び出しが成功したことを確認して、トークンがまだ有効であることを確かめます。スコープを取り消していないことを確かめます。いうファイルを作成し、そこに、これらの行を貼り付けます。'/'endコードの大部分は見慣れたもののはずです。結果をレンダリングするために結果を渡しています。メソッドを使用して、ユーザーが既に認証されていることを確認しています。フローを実行して、付与されたトークンとスコープでセッションを更新します。ファイルを作成し、このマークアップを貼り付けます。サーバーを起動します。リダイレクトされます。レンダリングされます。変更するだけで、このラウンドトリップ経路を完全に簡略化できます。依存しているため、機能させるには少し不安定なことを行う必要があります。データにアクセスするように認証したことがない場合、以前のポップアップと同じ確認ダイアログが表示され、警告されるでしょう。servicesBlog。