oauth2のフローで非対話型クライアントに対して新しいaccess_tokenを要求するタイミングは？

Question

非対話型クライアントに関する質問があります oauth2の流れに基づくバックエンドアプリです。

https://auth0.com/docs/api-auth/grant/client-credentials

非対話型のクライアントのためのOAuth2に従い、フローは次のとおりです。

• アプリケーションはAuth0はそのクライアントIDとクライアントシークレットを使用して認証します。
• Auth0はこの情報を検証し、access_tokenを返します。
• アプリケーションは、access_tokenを使用して、それ自体のためにAPIを呼び出すことができます。この上

ベース、私の質問は以下のとおりです。

• バックエンド・アプリケーションは、ローカルにaccess_tokenはを保存したり、同じクライアントのために、クライアントがアプリケーションを使用するたびに新しいaccess_tokenはを要求する必要がありますか？
• access_tokenがローカルに保存されている場合、有効期限のあるものは何ですか？
• 非対話型クライアントのアクセストークンは、対話型ユーザー（ログインWeb）のaccess_tokenと同じ有効期限を持つ必要がありますか？

Answer 1

バックエンド・アプリケーションは、ローカルにaccess_tokenはを保存する必要がありますまたはクライアントが アプリケーションを使用するたびに同じクライアントのために 新しいaccess_tokenはを要求しますか？クライアントの資格情報については

返さJWTアクセストークンがあなたの要件に依存する流れ、頻繁に更新するかどうかの決定、または「キャッシュ」を付与 - 例えばスコープが頻繁に変更された場合、それは新たなアクセスを取得しても意味がありこれらの変更が反映されるように頻繁にトークンを使用します。個人的な経験から言えば、これは一般的ではないので、有効期限の間トークンをキャッシュすることは理にかなっており、Auth0への余分な呼び出しを保存して、それぞれの要求で新しいトークンを取得します。

access_tokenがローカルに保存されている場合、有効期限が切れていますか？

期限切れをチェックして有効期限が切れた場合は新しいアクセストークンをフェッチするか、チェックせずにアクセストークンを使用してから試してみてください既存のトークンを使用しているときに障害を受け取ります。非対話型のクライアント用

access_tokenは、インタラクティブなユーザー （ログインWeb）用access_tokenはと比較して、同じ 有効期限を持っている必要がありますか？

最初のものと同様の質問です。クライアント資格認可フローを使用すると、通常は機密性の高い/信頼できるクライアント（クライアントシークレットを保管している）が表示されるため、マシンとマシンのシナリオで頻繁に使用されるため、有効期限が長くなります。しかし、すでに述べたように、スコープが変更された場合などは、有効期限が短くなると構成の変更（スコープ）がより迅速に行われます。