私は2つの別々のプロジェクトを作成した場合：ASP.NETコアWeb APIおよびMVCプロジェクトが別の場合のASP.NET IDの使用。どのような認証を処理する必要がありますか？
は、MVCプロジェクトは、Webに話をするのHttpClientを使用しますがAPI。
この場合、Web APIを使用して作成するか、MVCプロジェクトの一部として保持する必要がありますか？
あなたの質問の説明から、アプリケーションの1つのレイヤだけを保護するように思えます。
理想的には、両方を保護します。 MVCアプリケーション側では、resource authenticationまたはclient authenticationを実行して、API（アプリケーションx）の呼び出し元に実際にアクセスしているかどうかを確認するWebAPI側で、ASPNET ID（resource authenticationまたはclient authentication）を使用したい場合はuser authenticationにASPNET ID APIを呼び出す権利。後者はASPNET IDで行うことはできません。これを達成するには、Identity Server 4やAzure B2Cのようなものが必要です。
APIを開いたままで、MVC APPのHTTPClientから呼び出すことができます。なぜあなたはAPIが必要なのか考えることができる唯一の理由は、後で他のアプリからAPIを使用できるようになるため、APIをオープンにすることはお勧めできません。
私が靴を履いていた場合は、アプリケーションの周りにセキュリティフレームワークを用意し、必要な操作を実行するためにAPIに必要なアクセス権をアプリケーションに与えたいと考えています。
だから私はIDサーバー4（これまで私が以前使用していたもの）をAPIに追加するか、独自のプロジェクトとして追加することをお勧めします。クライアントアプリとAPI間の認証にこれを使用しますか？現時点では、MVCアプリケーションは、これが私が組み込みIDを使用する場所であると言っているのですか？ユーザーの登録やログインにもかかわらず？将来APIを呼び出すクライアントがユーザーを登録してログインできる必要がある場合はどうなりますか？おそらく、これがアイデンティティ・サーバーが出現する場所です。私が間違っているなら私を訂正してください。 –
トークンサーバーは独自のプロジェクトである必要があります。 IdSrv4は特に、OAuthとOpenId Connectの両方を行い、ユーザとクライアントの登録と認証の両方をこのプロジェクトに移すことができます。私の意見では、このようにすべてを簡単に管理することが簡単です。その後、MVCとWebAPIはこの認証サービスのコンシューマになります。 –
@MuqueetKhanクライアントの登録と認証をIdentityServer4プロジェクトに移すと言っています。私はこれを行う方法を知っているので、MVCアプリケーションはAPIにアクセスできます。ただし、ユーザーを認証して認証しようとすると、混乱が生じます。私は、MVCプロジェクトがIdentityServer4プロジェクトに飛んでユーザーがログインできると思っています。この場合、MVCプロジェクトでは、組み込みのASP.NET IDテンプレートとマネージャを使用して、誰がどのようなアクションにアクセスできるのかを言うことができますか？あるいはこれはすべてIdentityServer4の一部になるのだろうか？ –