IdentityServer3 | OpenID Connect Provider and OAuth | Authentication library

When using ASP.Net DI and IdentityServer DI together, we have to be careful to make sure that both the IdentityServer and the underlying DbContext are scoped to the OWIN request context, we do that by Injecting the DbContext into the IdentityServer context. this answer has some useful background: https://stackoverflow.com/a/42586456/1690217

I suspect all you need to do is resolve the DbContext, instead of explicitly instantiating it:

The error shows:

I further investigated with process monitor tool, compared the tcp operations between local and aws ec2 instance for the identityserver external login endpoint request then I found that TCP disconnect operation happening immediately after TCP connect in AWS ec2 instance but in local this was not happening instead TCP communication established and tcp communication went well.

Further investigated with wireshark tool then I found the Handshake failure happening in AWS ec2 instance after Client Hello call. Then I compared TLS version and cipher suites used by local machine (from wireshark log), I found the difference like local machine uses TLS 1.2 and cipher suite : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)

and AWS ec2 instance uses TLS 1.0 which is not supproted by ADFS server. Hence the tcp connection could not be established resulting into handshake failure.

I followed this link https://docs.microsoft.com/en-us/officeonlineserver/enable-tls-1-1-and-tls-1-2-support-in-office-online-server#enable-strong-cryptography-in-net-framework-45-or-higher to make .net framewrok to use strong crypto.

After this registry update, successfully able to login from external idp (ADFS) via identity server3 login page.

"id_token token" is Implicit flow, so you need to include that in your AllowedGrantTypes.

Re the UserInfo endpoint, it just returns claims about the user, based on the access token you call it with. Getting a 401 response probably means you aren't passing a valid access token. It can be useful if you need additional user claims and you only have an access token but not an ID token.

After many research, it is very easy and simple way to delete the cookies from the Postman application as shown below:

Then delete the cookies as shown below:

Now try to apply the request, it should work, but, this is only temporary solution, I hope there is a full solution from Postman team or someone.

Solution was not to use SwaggerConfig.Register() separately instead do this configuration inside WebApiConfig.

In the API, change ValidationMode = ValidationMode.ValidationEndpoint to ValidationMode = ValidationMode.Both. Which would enable Identity Server to use local validation for JWTs and validation endpoint for reference tokens.

Yes, it is stated that you should create an application for management of Users, Resources, etc.

Scott Brady states here that you can write your own API or use another package like IdentityManager.

However, IdentityManager package is no longer active, you can use IdentityServer4.Admin package instead.

As explained in your GitHub ticket:

IdentityServer is an OAuth implementation - what you are suggesting would be incompatible with OAuth and thus is not supported by us.

If you need to change the complete payload to something custom - write some middleware to intercept the response.