単一の認証ポイントの実装

単一の認証ポイントに接続された一連のWebアプリを構築しています。基本的に、ユーザーはサイトにアクセスしようとしますが、認証されていない場合、中央の認証システムのログインページにリダイレクトされます。ログインに成功すると、アプリにリダイレクトされます。それ以降、他のアプリにアクセスすると、自動的にサインオンされます。

さらにいくつかの詳細：1）アプリはすべて同じドメインで実行されるため、ドメインCookieを使用できるので、物事が簡単になります。2）ユーザーは一部のアプリへのアクセスを許可され、他のアプリへのアクセスは許可されない可能性があるため、考慮に入れる必要があります。3）ユーザーは、各アプリに固有の権限を取得できる必要があります。

私は何かを実装しましたが、100％満足していません。現在、これは私が持っているものです。1）Webアプリは、セッション（アプリに固有）の存在と、集中認証システムから送信されたJWTトークンであるCookieをチェックします。2）Cookieが存在しない場合、認証システムのログインページにリダイレクトします。3）ユーザーがログインすると、JWTトークンを渡してアプリにリダイレクトされます。4）アプリは、認証システムへのREST API呼び出しを介してトークンを検証します（このREST API呼び出しは別のアクセストークンに依存します）。有効な場合、JWTトークンはCookieとして保存され、セッションはユーザーがログインしました。5）アプリセッションの有効期限が切れた場合は、Cookieが存在するかどうかを確認し、存在する場合はステップ4と同じようにアプリがトークンを確認してセッションを再開します。6）ログアウト時に、システムはCookieを削除するだけです。ユーザーがすべてのアプリからログアウトしていることを確認します。7）トークンの有効期限が切れた場合、アプリは期限切れのトークンを使用して新しいトークンをリクエストします。トークン署名と他のクレームは、新しいトークンを発行する前に検証されます。検証されないのは、有効期限クレームのみです。

明確にするために、アプリに固有のセッションの存在が使用されているため、トークンを確認するためにREST API呼び出しを常に行う必要はありません。しかし、トークンが一度検証された場合、有効なセッションが存在することを示すインジケータとしてそのCookieを使用するだけで安全ですか？

よくわからないことの1つは、トークンを使用して他のREST API呼び出しを実行し、アプリ固有のリソースを取得できるため、トークンにはそれが何のアプリであるかを示すものが必要であるということです。しかし、app1のトークンを取得してからapp2にログインすると、app2はapp2によって生成されたCookieに依存します。つまり、2つのトークンが必要なようです。1つはユーザーが認証されたことを示すためにドメインCookieとして保存でき、もう1つは実際にアプリ固有であり、他のアプリのREST API呼び出しに使用できます。特定のリソース。

私はこれを複雑にしていますか、それとも私の考え方は他の人が見ている/行っていることと一致していますか？またはこれを行うよりエレガントな方法はありますか？私はOpen IDのようなものを実装することを考えましたが、私たちのニーズに対してはやり過ぎのようです。プロセスを文書化し、他の開発チームが多くの支援を必要とせずに認証システムにプラグインするアプリを開発できるように、これをできるだけ単純にしたいと思います。

夢中になるな。彼らの正しい心の中の誰も、このようなものをゼロから書き込もうとはしませんでした。OAuthを使用します。トークンのJWT Bearerトークン仕様を使用し、スコープを使用して、ユーザーがアクセスできるアプリまたはリソースを決定できます。これは、車輪の再発明を始めるのに適した領域ではありません。

私は最近、ここで、トークンベースの認証のセットアッププロセスを説明するガイドに従いました。アプリ固有のIDの何らかの形式を渡すことを想像できる1つの方法は、クレームを使用することです。

したがって、ログインシステムページにリダイレクトするWebサイトAがあります。ウェブサイトAは、ログイン後にユーザーをどこに連れて行くか、どこにウェブサイトAがあるかなど、他のいくつかのデータも渡しました。認証システムはこのデータを確認し、何らかの形のスイッチを使用して、現在のアプリのスコープを識別するクレームをユーザートークンに追加します。

また、ユーザーがアプリを非常に高速で切り替え、app2でapp1のアプリリソースにアクセスできるようにするため、access_tokensの有効期限が非常に速くなります。上記のガイドを使用して構築した私の実行中のデモWebサイトでは、毎分有効期限が切れます。また、refresh_tokenの実装により、すべてが簡単になります。役立つ可能性があるもう1つのステップは、ユーザーにクレームを追加するときに、Webサイトにいることを示す役割をそのユーザーに追加することです。

次に、app1の/ api / endpoint / getDataで[Authorize（Roles = "App1"）]を設定します。これにより、ロール= App1を含むaccess_tokensのみがそのエンドポイントを使用できるようになります。特定のエンドポイントにアクセスしないなどのエラーを論理的にチェックします。おそらく、ユーザーは更新トークンなどを使用して新しいaccess_tokenを取得する必要があります。

上記と同じガイドを使用して、そのリンクをたどってこれを検索します。

var identity = new ClaimsIdentity（context.Options.AuthenticationType）;

ご覧のとおり、IDは基本的にaccess_token内にカプセル化される単なる値であるクレームを追加しています。

これで、ユーザーがその上に承認された属性を持つWeb APIを呼び出すと、そのユーザーが主張することを確認するだけです。

この例はここにあります。