Identity Server 4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.
The Big Picture
Most modern applications look more or less like this:
The most common interactions are:
⦁ Browsers communicate with web applications
⦁ Web applications communicate with web APIs (sometimes on their own, sometimes on behalf of a user)
⦁ Browser-based applications communicate with web APIs
⦁ Native applications communicate with web APIs
⦁ Server-based applications communicate with web APIs
⦁ Web APIs communicate with web APIs (sometimes on their own, sometimes on behalf of a user)
Typically each and every layer (front-end, middle-tier, and back-end) has to protect resources and implement authentication and/or authorization – often against the same user store.
Outsourcing these fundamental security functions to a security token service prevents duplicating that functionality across those applications and endpoints.
Restructuring the application to support a security token service leads to the following architecture and protocols:
Such a design divides security concerns into two parts:
Authentication
Authentication is needed when an application needs to know the identity of the current user. Typically these applications manage data on behalf of that user and need to make sure that this user can only access the data for which he is allowed. The most common example for that is (classic) web applications – but native and JS-based applications also have a need for authentication.
The most common authentication protocols are SAML2p, WS-Federation, and OpenID Connect – SAML2p being the most popular and the most widely deployed.
OpenID Connect is the newest of the three but is considered to be the future because it has the most potential for modern applications. It was built for mobile application scenarios right from the start and is designed to be API friendly.
API Access
Applications have two fundamental ways with which they communicate with APIs – using the application identity, or delegating the user’s identity. Sometimes both methods need to be combined.
OAuth2 is a protocol that allows applications to request access tokens from a security token service and use them to communicate with APIs. This delegation reduces complexity in both the client applications as well as the APIs since authentication and authorization can be centralized.
OpenID Connect and OAuth 2.0 – better together
OpenID Connect and OAuth 2.0 are very similar – in fact, OpenID Connect is an extension on top of OAuth 2.0. The two fundamental security concerns, authentication, and API access are combined into a single protocol – often with a single round trip to the security token service.
We believe that the combination of OpenID Connect and OAuth 2.0 is the best approach to secure modern applications for the foreseeable future. Identity Server 4 is an implementation of these two protocols and is highly optimized to solve the typical security problems of today’s mobile, native, and web applications.
How Identity Server 4 can help
IdentityServer is middleware that adds the spec-compliant OpenID Connect and OAuth 2.0 endpoints to an arbitrary ASP.NET Core application.
Typically, you build (or re-use) an application that contains a login and logout page (and maybe consent – depending on your needs), and the Identity Server 4 middleware adds the necessary protocol heads to it so that the client applications can talk to it using those standard protocols.
The hosting application can be as complex as you want, but we typically recommend keeping the attack surface as small as possible by including authentication-related UI only.
Identity Server 4 implements the following specifications:
OpenID Connect
⦁ OpenID Connect Core 1.0 (spec)
⦁ OpenID Connect Discovery 1.0 (spec)
⦁ OpenID Connect RP-Initiated Logout 1.0 – draft 01 (spec)
⦁ OpenID Connect Session Management 1.0 – draft 30 (spec)
⦁ OpenID Connect Front-Channel Logout 1.0 – draft 04 (spec)
⦁ OpenID Connect Back-Channel Logout 1.0 – draft 06 (spec)
OAuth 2.0
⦁ OAuth 2.0 (RFC 6749)
⦁ OAuth 2.0 Bearer Token Usage (RFC 6750)
⦁ OAuth 2.0 Multiple Response Types (spec)
⦁ OAuth 2.0 Form Post Response Mode (spec)
⦁ OAuth 2.0 Token Revocation (RFC 7009)
⦁ OAuth 2.0 Token Introspection (RFC 7662)
⦁ Proof Key for Code Exchange (RFC 7636)
⦁ JSON Web Tokens for Client Authentication (RFC 7523)
⦁ OAuth 2.0 Device Authorization Grant (RFC 8628)
⦁ OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (RFC 8705)
⦁ JWT Secured Authorization Request (draft)
it enables the following features in your applications:
Authentication as a Service
Centralized login logic and workflow for all of your applications (web, native, mobile, services). IdentityServer is an officially certified implementation of OpenID Connect.
Single Sign-on / Sign-out
Single sign-on (and out) over multiple application types.
Access Control for APIs
Issue access tokens for APIs for various types of clients, e.g. server to server, web applications, SPAs, and native/mobile apps.
Federation Gateway
Support for external identity providers like Azure Active Directory, Google, Facebook, etc. This shields your applications from the details of how to connect to these external providers.
Focus on Customization
The most important part – many aspects of IdentityServer can be customized to fit your needs. Since IdentityServer is a framework and not a boxed product or a SaaS, you can write code to adapt the system the way it makes sense for your scenarios.
Mature Open Source
IdentityServer uses the permissive Apache 2 license that allows building commercial products on top of it. It is also part of the .NET Foundation which provides governance and legal backing.
Github link: https://github.com/Freelancingonupwork/IdentityServerWithMVC
Why need to implement an identity server
Example
Google is providing the multiple product and services for example drive, Gmail, slides, Contact, etc
All these services portal is having a different URL.
1 https://mail.google.com
2 https://drive.google.com
3 https://contact.google.com
4 https://slides.google.com
Since all the services running on different URLs. They need to protect the application access by implementing login/ authentication. It’s not a good idea to implement the login module for each and every service. Instead of that, they have a centralized login ( https://account.google.com ) which is responsible to authenticate the user who is trying to access any Google services
So this reduces the burden of application services to authenticate users. As this reprehensibility given to the separate application.