A fully functional. NET open source OpenID Connect/oauth 2.0 Framework--identityserver3

Today's recommendation is an open source OpenID Connect/oauth 2.0 Service Framework--identityserver3 that I've been focusing on for a long time. It supports the complete OpenID Connect/oauth 2.0 standard, which makes it easy to build a single sign-on server.

Said to have been concerned about, because 1 years ago, to build an OAuth 2.0 server for a platform, at that time because IdentityServer3 is still in the development phase, the core is not stable, the expansion function is not complete. Reluctantly, I had to familiarize myself with the OAuth 2.0 specification and implement it on a simple example on the Www.asp.net website. But now, IdentityServer3 officially released a stable version of 1.0 at the beginning of the year. Note: IdentityServer3 developers have IdentityServer2 products before, but IdentityServer3 based on Microsoft's latest ASP (such as Owin), in the form of middleware, more extensibility.

Why is there a framework like IdentityServer3? Modern applications are more or less the following architectures:

In this case, the front-end, middle-tier, and backend require authentication and authorization to protect resources, so the underlying security features cannot be implemented only at the business logic layer or the Service interface layer. In order to solve such problems, the following security architectures are often caused:

In fact, the entire security problem is broken down into two areas: Authentication and API access.

The so-called authentication is that the application needs to know who the current user is. Typically applications manage user information and access user-authorized resources on behalf of the user. This is common for typical web applications, but it also requires validation for native applications or JS-based applications. So the industry has developed a wide variety of common authentication protocols: saml2p, Ws-federation, and OpenID Connect. SAML2P was used extensively before, but as a rising star, OpenID Connect, which is essentially based on the OAuth 2.0 extension, is more suitable for modern applications, especially mobile applications.

For API access. The application has two ways of communicating with the API: using the application's own identity, or using the user's identity on behalf of the user. The OAUTH2 protocol allows an application to request an access token from the security token service and then use that token to communicate with the API (the API accesses the token server to verify that the visitor's token is valid). This reduces the complexity between the client application and the API, because both authentication and authorization are centralized.

Since OpenID Connect and OAuth 2.0 are very similar, IdentityServer3 's goal is to support both. It supports the following criteria:

• OpenID Connect Core 1.0:basic, implicit and hybrid flows
• OpenID Connect Discovery 1.0
• OpenID Connect Session Management 1.0-draft 22
• OAuth 2.0:authorization Code, implicit, resource owner password credentials and client credentials grant
• OAuth 2.0 Bearer Token Usage
• OAuth 2.0 Multiple Response Types
• OAuth 2.0 Form Post Response Mode
• OAuth 2.0 Token Revocation

IdentityServer3 as a framework with many extension points (see the Official Documentation Service Factory section), and also comes with a number of expansion packs:

• Core Package: Defines the core object model, service implementation, and server implementation. Built-in simple memory configuration and storage implementations for testing.
• Configure Storage Packages: Save configuration information (clients and scopes), with EF and MongoDB optional.
• User Store Package: Save user ID, with membershipreboot and ASP. NET identity Optional.
• Other plug-in packages: Ws-federation protocol support, access token authentication extension
• Third-party expansion packs: such as localized extensions, etc.

Finally, we would like to talk about whether we should use such a framework for our products (especially in more critical safety-related functions), that is, the question of whether to "reinvent the wheel".

In my opinion, "we can create our own cars over and over again, but never make the wheels again." Especially for small start-ups, small teams should devote their energies to quickly verifying business viability. First, there's no guarantee that you'll be more professional in making wheels than anyone else (like IdentityServer3 developers have been doing validation frameworks and servers), and second, The wheel maintainability You make is certainly harder than a ready-made wheel (unless you're going to build your own wheels because it's selfish to get someone to take over), and it's harder to learn from the wheels (other members of the team can't quickly start with the existing documents); and finally, if there's a shortage of off-the-shelf wheels, The correct attitude is to participate in the open source project to improve it to promote community development, rather than unworthy.

"Read the original" is the official document directory of IdentityServer3. You can read through the document first to determine whether to use your own product.

Original address: http://identityserver.github.io/Documentation/docs/

A fully functional. NET open source OpenID Connect/oauth 2.0 Framework--identityserver3