Securing Asp .NET Core Applications

Photo by FLY:D on Unsplash

In this article, I’ll begin a series in which I’ll try to explain identity concepts and how they are implemented in the.NET world. although, in principle, it could be applied to any language.

Post in the series

From the point of view of the client application, this blog series will look at the identity management lifecycle.

Pre-requisite : Knowledge of developing WebAPI

It is important to discuss the historical background of identity techniques before moving on to discuss contemporary methods.

Early Days

Most applications start out as Think client applications or server-side web applications that only work within a single organization's or website's domain.

However, Next Stage (SOA) has occurred, and we are no longer restricted to developing only domain-based services. This makes Windows Authentication less practical.

SOA and its cousins

SOA, or Service-oriented application, was one of the first kinds of Microservices. I think the name changed from SOA to Microservice over time because of marketing and new ways of doing things.

If you work in the dotnet space, most of the services were made with WCF. Most of the services are well within the company's domain, but users don't have to be there. It can be just a service to service.

Modern days

We develop APIs that are used by numerous devices, CLIs, and external applications. In practice, more bots than humans use our application. To be fair, the old method of authentication, "form-based authentication, is inapplicable to mobile because it lacks the concept of a form.

Even sending the username or password isn't possible because any tool that can sniff packets can easily get the information. When problems emerge, protocols also emerge.

To solve the problem of securely authenticating across multiple devices, the software community devised token-based security.

Token Based Security

Instead of sending the user name and password, the client application sends a token representing consent to the API. Two protocols, OAuth 2.0 and OpenID Connect, make this method possible.
In subsequent articles, we will explain how this protocol operates. I believe that when it comes to security, why is more important than how, so in addition to discussing how, we will also discuss why.
Also, in the past, each application managed its own auth and authz, but this has been eliminated with microservices and the management of the following concerns:

Managing these responsibilities in every application is going to be a nightmare, so it is better to have a centralized identity provider.

Central Identity Provider

In the upcoming blogs we will see how to implement our own identity provider and also how to integrate other identity providers. We will discuss about complete lifecycle of the identity that is

We’ll put OAuth and OpenID Connect into place. Last but not least, it’s important to know this:
OAuth is a protocol for giving an app permission to do something and getting an access token.
OpenID: This is the identity protocol that talks about how to make sure the client is who they say they are.
To say it again, don’t forget about OAuth-Authorize and OpenID-Authorize.

In the subsequent blog post, we will begin implementing the central identity provider.

Next blog Post : https://satish1v.medium.com/building-your-own-authentication-server-part-1-52c5f229b3ed

References

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store