This example by MicrosoftはOAuth 2.0認証サーバーの実装について説明しています。私は承認コード付与フローを実装しています。ダウンロードされたサンプルコードでは、/authorizeエンドポイントは、ログイン時にアクセス許可を与えるたびにユーザーに確認します。初めてログインするときに1回しか許可を与えないようにするために、これはデフォルトのためですか？OAuth 2.0は認証許可を覚えています
このシナリオでのベストプラクティスは何ですか？
ありがとうございます。
OAuth 2.0仕様自体には、この機能についての記載はありません。したがって、使用している認証サーバーの実装にこの機能がない場合は、それを実装する必要があります。
この機能を実現するには、に関する情報を格納する必要があります。ユーザーとクライアントアプリケーションの組み合わせごとに、who（ユーザー）がどのユーザーにどのアクセス許可（スコープ）を許可しましたか（クライアントアプリケーション）に関する情報を格納する必要があります。さらに、おそらく、ユーザーに再度尋ねることを避けるために、各組み合わせに発行されたすべてのアクセストークンが期限切れになった後でも、情報を保持したいことがあります。
私があなただったら、認証サーバーに内部APIを追加します。 APIはユーザーIDとクライアントIDを受け取り、過去にユーザーがクライアントアプリケーションに付与したスコープのリストを返します。このようなAPIがある場合は、認証ページを生成するときにそのAPIを使用できます。
"Granted Scopes API" が一例です。 /api/client/granted_scopes/get APIはsubjectとclientIdリクエストパラメータを受け取り、以下のようなJSONを返します。
{
"serviceApiKey" : <Service API Key>,
"clientId" : <Client ID>,
"subject" : <User's Unique ID>,
"latestGrantedScopes" : <Scopes granted by the last authorization process>,
"mergedGrantedScopes" : <All the scopes granted so far>,
}
/api/client/granted_scopes/delete APIはsubjectとclientIdリクエストパラメータを受け入れ、もしあれば思い出したレコードを削除します。
Granted Scopes APIは、専用のAuthleteサーバーでのみ機能することに注意してください。共有Authleteサーバー（api.authlete.com）では動作しません。 API呼び出し側が必要に応じて/api/client/granted_scopes/delete APIを呼び出さなければガベージレコードが蓄積され、そのようなガベージレコードが共有ストレージを浪費することがあります。