私は古典的なweb-appに対しての認証目的のためだけに承認コードGrant vs. Implicit Flowを使用する利点を理解できません。暗黙的な承認ワークフローの短所と認証コードの許可のみの認証?
と言えば、サードパーティのIaasプロバイダから認証されるウェブアプリがあります。 web-appはユーザー(あるIDで識別される)が認証されているかどうかだけを知る必要があります。 web-appはサードパーティーのサービスにヒットしないため、承認の目的でアクセストークンを持つ必要はありません。
この例では、IaaSから直接Webブラウザにuser_id(JWTトークン)を取得するのが安全でなく、Webバックエンド経由で同じuser_idを取得する方法がわかりません。どちらの場合も、セッションが確立されます。この場合暗黙的な助成金を使用すると、私は何を失いますか?
'認可コード'許可には、保護されたクライアントは必要ありません。そのグラントの種類は、スマートフォンのネイティブアプリケーションで使用することができます。適切な質問は、「クライアントがWebブラウザ内で**完全に**実行されているか」です。答えが「はい」の場合は、暗黙的な許可タイプを使用します。それ以外の場合は、「許可コード」(ネイティブ・アプリケーションの場合はPKCE)を使用します。 詳しい説明は、https://alexbilbie.com/guide-to-oauth-2-grants/または(優秀な本)https://www.manning.com/books/oauth-2-in-actionを参照してください。 –
私のサーバー上で実行されているWebサーバーへの要求を行うクライアントがブラウザで実行されています。 すべての文書には、認証コードの使用を提案しています。この場合、暗黙的な付与よりもどのように安全であるかはまだ分かりません。 たとえば、認可付与の場合、クライアントが認証されると、サーバはクライアントとのセッションをセットアップします。クライアントには同じuser_idが含まれている可能性があります。だから、認証サーバに二重の往復だけが追加されたようですね。 –
@MikhailY Id/Accessトークンはエンドユーザーのブラウザに移動する必要がないため、より安全です。 – iandayman