現在、私の Web サービスでは、app.UseWindowsAzureActiveDirectoryBearerAuthentication を活用して、AAD 発行のトークンとその素晴らしい機能を検証しています。OpenId Connect トークンに対して同様のことをしたいと思いますが、AAD に固有であり、基になるプロトコルについて何も述べていないため、UseWindowsAzureActiveDirectoryBearerAuthentication が正しいものであるかどうかはわかりません。他の 2 つのオプションは app.UseJwtBeararAuthentication と app.UseOAuthBeararAuthentication だけのようです。私が使用する ID プロバイダーはディスカバリーをサポートする可能性が高いため、有効なオーディエンス、発行者、およびディスカバリーまたはメタデータの URL を登録し、認証ミドルウェアに残りの処理を任せます (署名キーの取得、キャッシュ、有効期限の検証、 UseWindowsAzureActiveDirectoryBearerAuthentication で行うのと同じように、発行者、対象ユーザーなど)。
質問する
663 次
2 に答える
0
Web サービスにアクセスするときに OpenID Connect が追加する魔法のソースは実際にはありません。それはすべて OAuth2 とほぼ同じです。そのために、RFC 6750 の「The OAuth 2.0 Authorization Framework: Bearer Token Usage」を引き続き使用します。Web API に送信されるトークンはアクセス トークンであり、OpenID Connect でも不透明なままです。あなたが説明している機械はid_tokens用であり、これらはすべてブラウザ経由で配信されるアプリに依存する許可によって取得されます(したがって、Web サービスではなく、UX またはネイティブクライアントを提供する Web アプリ）。Web サービスの場合、クライアントは必ずしも Web ブラウザーであるとは限りません。そのため、通常、アクセスには RFC 6750 を使用します。現在: Azure AD はたまたま id_token とアクセス トークンの両方に同じトークン形式と同じ署名キーを使用しています。これがおそらく、アプローチが一般化された可能性があると考えた理由です。他のプロバイダーに一般化しないアプローチ - Web サービス/API 用。それはWeb UXのために行います。
于 2015-03-25T08:18:20.243 に答える
0
app.UseWindowsAzureActiveDirectoryBearerAuthentication とアプリの両方。UseJwtBearerAuthentication は UseOAuthBeararAuthentication ミドルウェアを内部的に呼び出します。前者は xml 用で、後者は jwt トークン用です。app.UseJwtBearerAuthentication が要件を満たすことをお勧めします。
于 2015-03-25T06:25:17.650 に答える