OAuthv2認証付与
OAuthv2に関するこの優れたチュートリアル を読みましたが、承認付与に関するいくつかの重要な概念がまだ欠落しています。
私は基本的に、クライアントアプリと承認サーバーの間の2つの要求/応答サイクルの必要性を理解していません。ここで：
- 最初に、ユーザーは承認リクエスト中に認証サーバーにリダイレクトされます。これにより、（認証が成功すると）ユーザーは認証コード;その後
- 次に、クライアントアプリは認証サーバーに対して2番目のトークンリクエストを行います。これにより、認証サーバーはクライアントのID、シークレット、認証コードを検証し、送り返します。使用するためのアクセストークン
認証コードとアクセストークン
この「認証コード」とこの「アクセストークン」の違いは何ですか？なぜ最初に認証コードを生成して、後でアクセストークンを取得できるようにする必要があるのですか？！？ これをすべて1回のラウンドトリップで実行し、認証が成功したときにアクセストークンを取得しないのはなぜですか？
アクセストークンとリソースサーバー
アクセストークンの主なポイントは、将来のリクエストのホールパスとして機能することであり、クライアントアプリが後続の各リクエストを再認証しないようにすることだと思います。エルゴ有効なアクセストークンがあれば、クライアントアプリはリソースサーバーと「直接話す」ことができると思います。そして、各リクエストを受信すると、リソースサーバーはおそらくそれぞれの認証サーバーでアクセストークンを検証すると思います。 私はここで軌道に乗っているのですか、それとも基地から離れていますか？
アクセストークンとSSO？
複数のリソースサーバーがすべて同じ認証サーバーを使用しているSSOシナリオでアクセストークンを使用できますか？つまり、認証サーバーで認証すると、 1つのSSOアプリ内にいるときにアクセストークンを受け取り、別のSSOアプリに移行して、同じアクセストークンを適用し（まだ有効期限が切れていない場合）、その2番目のアプリに「サインイン」できますか。再認証する必要はありませんか？
認証コードgrant を使用すると、他のgrantにはない2つのことがわかります。
ユーザーとクライアントの両方の認証を提供します。アクセストークンを取得するときにクライアントIDとクライアントシークレットを送信することでクライアント認証を行います。
これにより、アクセストークンがユーザーエージェント（通常はブラウザ）から隠されたままになり、盗まれやすくなります。
暗黙の付与 は、実際にはこれをすべて1回のラウンドトリップで実行するため、アクセストークンをユーザーエージェントに公開し、クライアント自体（ユーザーのみ）を認証しません。
クライアントが各リクエストを再認証することなく、アクセストークンを使用してリソースサーバー上のリソースにアクセスできることは正しいです。リソースサーバーは、トークンの内容を信頼するために デジタル署名 を使用するため、トークンを検証するために承認サーバーと通信する必要はありません。
アクセストークンはSSOシナリオで使用できますが、通常、ユーザーエージェントは認証サーバーに戻って別のアクセストークンを取得し、別のリソースサーバーと通信します。ユーザーエージェントは、再認証を防ぐために、認証サーバーとのセッション（Cookieの可能性が高い）を確立します。