概要
最近のアプリケーションは、主に次のようになります：
最も一般的な相互作用は次のとおりです。
- ブラウザは、Webアプリケーションと通信します
- WebアプリケーションとWeb APIの通信（時にはユーザーに代わって、分離）
- Webベースのアプリケーションと通信するためのブラウザAPI
- ネイティブアプリケーションは、Web APIと通信します
- アプリケーションサーバーとWebベースの通信API
- 通信するためのWeb APIのWeb API（時にはユーザーに代わって、分離）
典型的には、各レイヤ（前端、後端および中間層）を保護する必要があり、リソースは、認証および/または許可されている - 多くの場合、同じユーザのために保存しました。
これらの基本的なセキュリティ機能は、それらのアプリケーションとエンドポイント間のセキュリティトークンサービス機能の繰り返しを防ぐために外部委託します。
セキュリティトークンサービスをサポートするための再編・アプリケーションは、次のアーキテクチャとプロトコルになります。
この設計は、セキュリティ上の問題は二つの部分に分割されます。
認証
アプリケーションは、現在のユーザーの身元を知っている必要がある場合には認証が必要です。一般的に、ユーザ管理データの代わりに、これらのアプリケーション、およびユーザーがアクセスを許可する唯一のアクセスデータをできるようにする必要があります。最も一般的な例は、（古典的な）Webアプリケーションですが、JSベースのマシンとアプリケーションは、認証が必要です。
最も一般的な認証プロトコルはSAML2p、WS-FederationのとOpenIDの接続-SAML2pは最も人気があり、最も広く導入されているプロトコルです。
OpenIDの接続は、3人の中で最新のものですが、それは現代のアプリケーションで最大の可能性を持っているので、将来のことを考えられています。これは、モバイルアプリケーションのシナリオのために最初から構築、そして優しいAPIを達成することを目指しています。
APIへのアクセス
アプリケーションIDまたは委任されたユーザーを使用 - アプリケーションや通信APIの二つの方法は基本的にあります。時にはそれは、二つの方法の組み合わせを必要とします。
OAuth2は、セキュリティトークンサービスからのアプリケーション要求のアクセストークンを可能にし、APIと通信するためにそれらを使用するプロトコルです。集中型の認証および承認するので、これは委任クライアントアプリケーションとAPIの複雑さを軽減します。
OpenIDを接続し、OAuth 2.0の - 一緒に、より良いです
OpenIDの接続とOAuth 2.0のは非常に類似している - 実際には、OpenIDの接続は、拡張のOAuth 2.0です。両方の基本的なセキュリティ問題への認証とAPIアクセスが合意に結合されている - 通常、一度だけとセキュリティトークンサービスから。
私たちは、組み合わせのOpenID ConnectおよびOAuth 2.0のは、予見可能な将来において、最良の方法は、最新のアプリケーションを保護することであると信じています。IdentityServer4は、これら2つのプロトコルを達成することである、と非常に一般的なセキュリティ上の問題ネイティブおよびWebアプリケーション、今日の動きに対処するために最適化されています。
どのようにIdentityServer4ヘルプ
IdentityServerは、任意のASP.NETコア・ミドルウェア・アプリケーションに追加対応のOpenID ConnectとOAuth 2.0のエンドポイントです。
通常は、あなたが構築（または再利用）ログインおよびログアウトページ（ものことを同意する必要があり - ご要望に応じて）を含むクライアントアプリケーションができるようなアプリケーションを、IdentityServerミドルウェアは、ヘッドこれに必要な契約を追加します対話の標準プロトコルを使用したもの。
あなたが必要としてあなたは複雑なように、ホストアプリケーションを使用することができます。しかし、可能な限り小さく、攻撃面を維持するために、我々は一般的に、あなただけ認証関連のUIが含まれていることをお勧めします。
関連用語
IdentityServer
OpenIDの接続とのOAuth2プロトコルを実装 - IdentityServerプロバイダOpenIDの接続です。
同じ役割のために、異なる文書が異なる用語を使用します - あなたはまた、セキュリティトークンサービス（セキュリティトークンサービス）、アイデンティティプロバイダ（IDプロバイダ）、認証サーバ（認証サーバ）、IP-STSなどを見つけることができます。使用するクライアントソフトウェアに発行されたいくつかのセキュリティトークン：しかし、彼らはすべて同じ意味を持ちます。
IdentityServerは責任と機能の一部が含まれています。
- あなたのリソースを保護
- ユーザー認証用のローカルアカウントストアまたは外部IDプロバイダーを使用して
- セッション管理とシングルサインオン（シングルサインオン）を提供します
- クライアント管理と認証
- クライアントトークンとアクセストークンのアイデンティティを解除するには
- 認証トークン
ユーザー
登録済みのお客様で、関連するデータにアクセスするエンドユーザー。
クライアント
クライアントソフトウェアは、のIdentityServerからのリクエストトークン（トークン）の一部である - ユーザーを認証するか（つまり、要求がIDトークンである）、またリソース（つまり、要求がアクセストークンである）にアクセスすることができ。クライアントは、最初のIdentityServer要求に関連するトークン化するために登録する必要があります。
クライアントは、その上のWebアプリケーション、モバイルクライアントやデスクトップアプリケーション、単一ページのアプリケーション（SPA、シングルページアプリケーション）、サーバプロセス、およびすることができます。
リソース
リソースは、あなたがIdentityServer保護を渡したいものです - 両方のユーザーID情報もAPIかもしれことができます。
各リソースには固有の名前を持っている - クライアントがアクセスするリソースを指定するには、これらの名前を使用します。
IDデータ（識別データ）は、ユーザーのID情報、名前（名）と電子メールアドレス（メールアドレス）として（も知られている請求）、です。
APIのリソースを使用すると、クライアントを呼び出したい関数で表し - 通常のWeb APIを介してAPIのリソースをモデル化するために、これは必ずしも必要ではありません。
アイデンティティトークン
IDトークンは、認証プロセスの出力を表しています。また、ユーザの認証と認証タイプが含まれています。最小限（被写体項別名サブ呼び出され、マスター識別情報、テキストの部分集合と呼ぶことができる）、ユーザが識別されます。アイデンティティトークンは、追加の識別データを含むことができます。
アクセストークン
アクセストークンは、APIリソースへのアクセスを許可するために使用します。クライアントがアクセストークンは、その後、APIを向けられている要求します。情報によってそれらに付与された情報、APIデータへのアクセス権（いずれかを提供している場合）アクセストークンは、クライアントとユーザーが含まれています。