Once you have added the MVC UI assets, you will also need to add MVC to the hosting application, both in the DI system and in the pipeline.
Add MVC to ConfigureServices with the AddMvc extension method:

The release branch of the UI repo has the UI that matches the latest stable release. The dev branch goes along with the current dev build of IdentityServer4. If you are looking for a specific version of the UI - check the tags.

Spend some time inspecting the controllers and models, the better you understand them,
the easier it will be to make future modifications.
Most of the code lives in the “Quickstart” folder using a “feature folder” style.
If this style doesn’t suit you, feel free to organize the code in any way you want.

Next you will add an MVC application to your solution.
Use the ASP.NET Core “Web Application” (i.e. MVC) template for that.
Don’t configure the “Authentication” settings in the wizard – you will do this manually in this quickstart.
Once you’ve created the project, configure the application to use port 5002 (see the overview part for instructions on how to do that).

To add support for OpenID Connect authentication to the MVC application, add the following to ConfigureServices in Startup:

AddAuthentication adds the authentication services to DI.
We are using a cookie as the primary means to authenticate a user (via "Cookies" as the DefaultScheme).
We set the DefaultChallengeScheme to "oidc" because when we need the user to login, we will be using the OpenID Connect scheme.

We then use AddCookie to add the handler that can process cookies.

Finally, AddOpenIdConnect is used to configure the handler that perform the OpenID Connect protocol.
The Authority indicates that we are trusting IdentityServer.
We then identify this client via the ClientId.
SignInScheme is used to issue a cookie using the cookie handler once the OpenID Connect protocol is complete.
And SaveTokens is used to persist the tokens from IdentityServer in the cookie (as they will be needed later).

As well, we’ve turned off the JWT claim type mapping to allow well-known claims (e.g. ‘sub’ and ‘idp’) to flow through unmolested:

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

And then to ensure the authentication services execute on each request, add UseAuthentication to Configure in Startup:

The authentication middleware should be added before the MVC in the pipeline.

The last step is to trigger the authentication handshake. For that go to the home controller and
add the [Authorize] on one of the actions.
Also modify the view of that action to display the claims of the user, e.g.:

Similar to OAuth 2.0, OpenID Connect also uses the scopes concept.
Again, scopes represent something you want to protect and that clients want to access.
In contrast to OAuth, scopes in OIDC don’t represent APIs, but identity data like user id,
name or email address.

Add support for the standard openid (subject id) and profile (first name, last name etc..) scopes
by adding a new helper (in Config.cs) to create a collection of IdentityResource objects:

The last step is to add a new configuration entry for the MVC client to IdentityServer.

OpenID Connect-based clients are very similar to the OAuth 2.0 clients we added so far.
But since the flows in OIDC are always interactive, we need to add some redirect URLs to our configuration.

Add the following to your clients configuration:

publicstaticIEnumerable<Client>GetClients(){returnnewList<Client>{// other clients omitted...// OpenID Connect implicit flow client (MVC)newClient{ClientId="mvc",ClientName="MVC Client",AllowedGrantTypes=GrantTypes.Implicit,// where to redirect to after loginRedirectUris={"http://localhost:5002/signin-oidc"},// where to redirect to after logoutPostLogoutRedirectUris={"http://localhost:5002/signout-callback-oidc"},AllowedScopes=newList<string>{IdentityServerConstants.StandardScopes.OpenId,IdentityServerConstants.StandardScopes.Profile}}};}

Trigger the authentication handshake by navigating to the protected controller action.
You should see a redirect to the login page at IdentityServer.

After successful login, the user is presented with the consent screen.
Here the user can decide if he wants to release his identity information to the client application.

Note

Consent can be turned off on a per client basis using the RequireConsent property on the client object.

..and finally the browser redirects back to the client application, which shows the claims
of the user.

Note

During development you might sometimes see an exception stating that the token could not be validated. This is due to the fact that the signing key material is created on the fly and kept in-memory only. This exception happens when the client and IdentityServer get out of sync. Simply repeat the operation at the client, the next time the metadata has caught up, and everything should work normal again.

With an authentication service like IdentityServer, it is not enough to clear the local application cookies.
In addition you also need to make a roundtrip to IdentityServer to clear the central single sign-on session.

The exact protocol steps are implemented inside the OpenID Connect middleware,
simply add the following code to some controller to trigger the sign-out:

Next time you authenticate, your claims page will now show the additional claims.

Feel free to add more claims - and also more scopes. The Scope property on the OpenID Connect
middleware is where you configure which scopes will be sent to IdentityServer during authentication.

It is also noteworthy, that the retrieval of claims for tokens is an extensibility point - IProfileService.
Since we are using AddTestUsers, the TestUserProfileService is used by default.
You can inspect the source code here
to see how it works.