2017-05-16 3 views
0

私は古典的なweb-appに対しての認証目的のためだけに承認コードGrant vs. Implicit Flowを使用する利点を理解できません。暗黙的な承認ワークフローの短所と認証コードの許可のみの認証?

と言えば、サードパーティのIaasプロバイダから認証されるウェブアプリがあります。 web-appはユーザー(あるIDで識別される)が認証されているかどうかだけを知る必要があります。 web-appはサードパーティーのサービスにヒットしないため、承認の目的でアクセストークンを持つ必要はありません。

この例では、IaaSから直接Webブラウザにuser_id(JWTトークン)を取得するのが安全でなく、Webバックエンド経由で同じuser_idを取得する方法がわかりません。どちらの場合も、セッションが確立されます。この場合暗黙的な助成金を使用すると、私は何を失いますか?

答えて

1

あなたのweb-appの実行場所に依存します。 Authorization code補助金が機密クライアント用に最適化されているため、ブラウザ上で完全に実行されている場合(JavaScriptアプリやSPAなど)は、implicitフローを使用します。

あなたのWebアプリは、サーバ上で実行されている場合は、トークンがWebアプリケーションサーバ(クライアント)に直接IaaS事業者(認証サーバ)から送信されるので、それはAuthorization code助成金を使用した方が安全ですし、ユーザーのブラウザ(リソース所有者)のブラウザではありません。

+0

'認可コード'許可には、保護されたクライアントは必要ありません。そのグラントの種類は、スマートフォンのネイティブアプリケーションで使用することができます。適切な質問は、「クライアントがWebブラウザ内で**完全に**実行されているか」です。答えが「はい」の場合は、暗黙的な許可タイプを使用します。それ以外の場合は、「許可コード」(ネイティブ・アプリケーションの場合はPKCE)を使用します。 詳しい説明は、https://alexbilbie.com/guide-to-oauth-2-grants/または(優秀な本)https://www.manning.com/books/oauth-2-in-actionを参照してください。 –

+0

私のサーバー上で実行されているWebサーバーへの要求を行うクライアントがブラウザで実行されています。 すべての文書には、認証コードの使用を提案しています。この場合、暗黙的な付与よりもどのように安全であるかはまだ分かりません。 たとえば、認可付与の場合、クライアントが認証されると、サーバはクライアントとのセッションをセットアップします。クライアントには同じuser_idが含まれている可能性があります。だから、認証サーバに二重の往復だけが追加されたようですね。 –

+0

@MikhailY Id/Accessトークンはエンドユーザーのブラウザに移動する必要がないため、より安全です。 – iandayman