web-dev-qa-db-ja.com

サイトをREST APIとWebアプリ(AspNetCore MVC)に分割するための承認と認証の設計

プロジェクトをモノリシックからサーバー側に分割することを検討していますREST APIと独立したWebベースのフロントエンド(または、他のサードパーティのコンシューマー)で、個別のサーバーとドメインでホストできます。 。

ユーザーの認証と承認にはどのようにすればよいですか?フォーム認証は基本的になくなり、すべての呼び出しは、APIエンドポイントへの呼び出しと同じ方法で処理されます。

サーバー側REST APIはゲートキーパーであり、条件付きでのみアクセスを許可します。標準のC#ASP.Netメンバーシップを理想的に使用します。フレームワークはMVC 6のASPNetCoreです。

1
Steve Hibbert

まず、ASP.NET CoreはMembershipをサポートしなくなったため、Identityを使用する必要があります。

私は最近、アプリケーションが成長するにつれて自分自身でそのような要件に遭遇し、毎回、それぞれにメンバーシップ/アイデンティティを実装する必要がありました。

私が思いついたソリューションは、ユーザーの資格情報を受け入れ、データベースに接続し、資格情報を認証し、トークンを生成/返すトークン(JWT)を集中管理する認証サーバーを構築することでした。このトークンは、クレームを通じて認証と承認の両方の目的を果たします。このアプリケーション/サーバーのみがIDを実装します。

保護されたリソース(Authorize)を持つクライアントアプリケーションでは、トークンを読み取ってクレームを検証するミドルウェアを実装する必要があります。ミドルウェアがクレームを検証するためにデータベースに再度接続する必要はありません。このトークンは、保護されたリソースに対してリクエストが行われるたびにAuthorizationヘッダーに追加されます。

同じ認証サーバーを使用する新しいアプリケーションを作成するたびに、検証ミドルウェアを実装または挿入するだけで済みます。 IDを再実装する必要はありません。

基本と実装の詳細については、以下のリソースを参照してください。

参照:

  1. https://docs.Microsoft.com/en-us/aspnet/core/security/authentication/identity
  2. https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/claims
  3. https://stormpath.com/blog/token-authentication-asp-net-core
  4. https://jwt.io/

基本を終えたら、追加のリソース:

  1. https://stackoverflow.com/questions/18223868/how-to-encrypt-jwt-security-token/44195678#comment75530351_44195678
  2. https://stackoverflow.com/questions/44179525/asp-net-core-jwt-bearer-token-custom-validation/44320206#44320206

注:私のシナリオでは、すべてのアプリケーションが同じデータベースと対話します。

3
Sang Suantak

フロントエンドとバックエンドを分離することは間違いなく良い考えです。認証と承認には、 project があり、これはangular5をフロントエンドとして使用し、asp.netコアをバックエンドとして使用します。 aspnetcore.IdentityとOpenIdConnectを使用します。うまくいけば、それで何かを見つけることができます。

0
bbusdriver