The Big Picture¶

最近のアプリケーションのほとんどは、このように見えます。:

最も一般的な相互作用は次のとおりです。:

ブラウザはウェブアプリケーションと通信する
WebアプリケーションはWeb APIと通信します（時には、ユーザー自身のために、時にはユーザーのために）
ブラウザベースのアプリケーションはWeb APIと通信します
ネイティブアプリケーションはWeb APIと通信します
サーバーベースのアプリケーションがWeb APIと通信する
Web APIはWeb APIと通信します（時には、ユーザー自身のために、時にはユーザーのために）

通常、各層（フロントエンド、ミドルエンド、バックエンド）は、リソースを保護し、認証や認可を実装する必要があります。

これらの基本セキュリティー機能をセキュリティー・トークン・サービスにアウトソーシングすると、それらのアプリケーションとエンドポイント間でその機能が重複することはありません。

セキュリティトークンサービスをサポートするようにアプリケーションを再構築すると、次のアーキテクチャとプロトコルが使用されます。:

このような設計は、セキュリティ上の懸念を2つの部分に分けます。:

認証¶

アプリケーションが現在のユーザーの身元を知る必要がある場合、認証が必要です。通常、これらのアプリケーションはそのユーザーに代わってデータを管理し、このユーザーが許可されているデータにのみアクセスできるようにする必要があります。そのための最も一般的な例は、（古典的な）Webアプリケーションですが、ネイティブおよびJSベースのアプリケーションでも認証が必要です。

最も一般的な認証プロトコルは、SAML2p、WS-Federation、OpenID Connectです。SAML2pが最も普及し、最も広く普及しています。

OpenID Connectは3つのうち最新のものですが、現代的なアプリケーションの可能性が最も高いため、将来のものと考えられています。当初からモバイルアプリケーションのシナリオ用に開発されたもので、APIに対応するように設計されています。

APIアクセス¶

アプリケーションには、アプリケーションIDを使用するか、またはユーザーのIDを委任する、APIと通信する2つの基本的な方法があります。場合によっては、両方の方法を組み合わせる必要があります。

OAuth2は、アプリケーションがセキュリティトークンサービスからのアクセストークンを要求し、それらを使用してAPIと通信できるようにするプロトコルです。この委任により、認証と承認を一元化できるため、クライアントアプリケーションとAPIの両方の複雑さが軽減されます。

OpenID ConnectとOAuth 2.0 - より良い連携¶

OpenID ConnectとOAuth 2.0は非常によく似ています - 実際、OpenID ConnectはOAuth 2.0の上に拡張されています。基本的なセキュリティ上の2つの懸念事項、認証とAPIアクセスは、1つのプロトコルに統合されます。セキュリティトークンサービスへの1回のラウンドトリップが頻繁に行われます。

OpenID ConnectとOAuth 2.0の組み合わせは、近い将来、最新のアプリケーションを保護するための最良のアプローチだと考えています。IdentityServer4は、これら2つのプロトコルの実装であり、今日のモバイル、ネイティブ、およびWebアプリケーションの典型的なセキュリティ問題を解決するために高度に最適化されています。

IdentityServer4がどのように役立つか¶

IdentityServerは、仕様準拠のOpenID ConnectおよびOAuth 2.0エンドポイントを任意のASP.NET Coreアプリケーションに追加するミドルウェアです。

通常、ログインとログアウト・ページを含むアプリケーションを構築（または再利用）します（必要に応じて合意することもできます）。IdentityServerミドルウェアは、クライアント・アプリケーションがそれに対話できるように、必要なプロトコル・ヘッドを追加しますそれらの標準プロトコルを使用しています。

ホスティングアプリケーションは、必要なだけ複雑にすることができますが、認証関連のUIだけを含めることで、攻撃の可能性をできるだけ小さくすることをお勧めします。