Basics Of IdentityServer4

Overview Of IdentityServer 4

A key feature of IdentitySever4 is that it is built on OpenID Connect and OAuth2.0, so you get benefits and features such as a centralized authentication service for all client applications, and multiple applications can be identified under one single login through IdentitySever4.

The diagram below illustrates the user trying to access resources, like credit card service and customer service, but they need to access those resources via a client, such as a web app or mobile app.

You will see an example of a banking application to demonstrate identityserver4 in more detail. ABC bank application is divided into 3 parts: 

1. Bank API, 
2. Console client 
3. Identity Server. 

You will need to know how Identityserver4 works with these three applications which will help you to better understand it.

Identity Server 4 Configuration

The Identity server middleware package can be installed using the NuGet package manager, as shown in the below screenshot.

As you will notice in the below screenshot the Idenityserver4 package includes idenityModel, Cors, jwt token, and Cryptography all those NuGet packages ready.

Configure the IndenityServer services into StartUp.cs Class

IdentityServer4 package is a combination of middleware and Services as you will see in the below screenshot. Configuration is done in ConfigureServices method and Configuration method to specify how a user is managed what clients to connect to and what resources Identityserver4 will protect.

ConfigurationService

You add the IdenitityServer service to the Dependency Injection,

1. AddDeveloperSigningCredential
   It's used to sign a certificate and token everything. It can be used as a sign-in credential to test developer mode. The generated key is persisted locally by default.
2. AddInMemoryApiResource
   Specify the in-memory collection of the API resource, in this case, Customer API is a resource. In order to access the resource, users need to use a client application, which includes mobile apps, web applications, and console apps. For a better understanding, refer to the beginning diagram
3. AddInMemoryClient
   Based on an in-memory collection of Client configuration objects. Configuration is done using the extension method.

In-Memory Configuration

“in-memory” configuration allows for configuring IdentityServer from an in-memory configuration objects list. The “in-memory” collections can be hard-coded or could be dynamically derived from either a configuration file or a database.

Configure the client and Resource in the config class 

The screenshot below shows two static methods are defined, one of them GetAPIResource and the other GetClients

GetClient

Looks up clients given a client ID. The return of an object (of type Client) contains, information about the client’s name, allowed grant types and scopes, the client secret.

Securing Web API Using Identity Server

You need to install IdenitytServer4TokenValidation in your Web API. The package helps you to add an authentication handler, idea behind is to validate the token with the help of IdenitytServer4TokenValidation package See the screenshot for reference

Configure API Startup for Authentication

See the screenshot below that will help you to better understand how to set up the plugging for indenityServer4

APiName: is part of the IndentiySever Config class.

Add the UseAuthentication Middleware in Configure Method, then you have to decorate the controller with Authorize attributes to secure the Web API Controller. Once the controller is decorated with authorized attributes, then it is no longer available without an authorization check. As you can see in the screenshot below.

You can check the API response 401 after securing API with authorize Attribute.

Consume to Secure API using Console Client

Use to console application as a client to consume secure API. You can see in the code that it mainly contains three sections.

1. Getting all metadata of identity sever
2. Get bearer token
3. Consume our Customer API

Getting all metadata of identity to sever

 DiscorveryClient

It provides you with a list of services that match a specific set of criteria and which allow you to connect to the services. The Discovery Endpoint is used to retrieve metadata about identityServer, and it returns the authorized endpoint, issuer name, key, material, token endpoint.

The screenshot below illustrates how to get the discovery object identity to sever.

Response

Bearer token

A Bearer Token is the most common method of accessing an OAuth2.0 API; it does not require the cryptography signing of each request. A single string used to authenticate API requests and requests made over an HTTP Authorization Header. The Bearer Token has the advantage that it does not require complex libraries to make requests, and making implementation much simpler for the client and server.

The below screenshot shows how you can get the bearer token from the identity server

HTTPClient

The HttpClient class handles sending and receiving HTTP requests and responses from resources identified by a URL. With it, you can use the async feature of .Net.

Below is a screenshot showing how to consume the Customer API using HttpClient.

Grant Type

The Grant Type describes how the client communicates with the resources or the way it talks to the authentication server or identity server in our case.

You can specify the grant types a client can use via the AllowedGrantype property on the Client Configuration. It is possible to configure a client to accept multiple grant types for a single user.

Client credentials

Machine to machine/ server to server communication tokens are always requested on behalf of a client, there is no interactive user is present.

Using the client credentials grant type, you send a token request to the token endpoint. Get the client's access token back. With the help of the client Id and secret, the client authenticates with the token endpoint.

Resource owner password grant type :

You can use the Resource Owner Password to request tokens on behalf of a user to send the user name and password to the token endpoint. Non-interactive authentication. A user is involved with a trusted 1st party app (mobile app) that handles the user's credentials (password).

By implementing the IResourcerOwnerPasswordValidator interface, you must provide code to validate the user name and password.

Authorization code

Tokens are retrieved back to authorization channels like Google and Facebook after the user login the user name and password are sent back to the authorization code. Authentication by authorization code is also supported.

Implicit

This grant type is optimized to be used with browser-based applications, server-side applications, and JavaScript applications.
If the client redirects to the user and the user to identityserver4 and the user login with credentials username and password, the identity server returns the token, the token is transmitted via browser to access the resource.

Hybrid

Hybrid is the combination of implicit and authorization codes. In other words, it is a combination of multiple grant types. Identity tokens are transmitted via the browser and contain a single protocol response and signature