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
- Building your own Authentication Server
- Building Your own Authentication Server — UI
- Adding Test users to Authentication Server
From the point of view of the client application, this blog series will look at the identity management lifecycle.
- Capabilities to Sign In and Sign Out
- API Access Methods
- integrating with your own identity provider and others like Google, Facebook, etc.
- How to deploy a identity server into Production
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.
- Client applications that support Windows Authentication provide the same level of security for users.
- When it comes to the server side of our web applications, we use either Windows or Form authentication.
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.
- Ws-Security is used in most case and its by far one of the difficult to understand XML
- IP-level configuration — Allow only machines with the specific IP
- SAML 2.0 — SAML was introduced in the same period but has a place in the modern Application.
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:
- Token expiration
- signing
- Token format
- Securely storing credentials
- Implementing changes in Protocol
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
