Overview
Modern applications are mostly looks like this:
The most common interaction is:
- The browser communicates with the Web application
- Web applications and Web API communication (sometimes separate, sometimes on behalf of users)
- Application Browser API to communicate with the Web-based
- Native applications communicate with the Web API
- Application server and Web-based communication API
- Web API Web API to communicate with (sometimes separate, sometimes on behalf of the user)
Typically, each layer (the front end, a rear end and an intermediate layer) must be protected and the resource is authenticated and / or authorized - often stored for the same user.
These basic security functions outsourced to prevent the repeat of the security token service function between those applications and endpoints.
Reorganization application to support the security token service will result in the following architectures and protocols:
This design will be security issues divided into two parts:
Authentication
When the application needs to know the identity of the current user is required to authenticate. Typically, these applications on behalf of the user management data, and the need to ensure that users can only access data that allow access. The most common example is the (classic) Web application, but the JS-based machines and applications also require authentication.
The most common authentication protocol is SAML2p, WS-Federation and OpenID Connect-SAML2p is the most popular and most widely deployed protocol.
OpenID Connect is the latest among the three persons, but is considered to be the future, because it has the greatest potential in modern applications. It will be constructed from the outset for mobile application scenarios, and aims to achieve a friendly API.
API access
There are basically two ways of application and communication API - use the application identity or delegated user. Sometimes it requires a combination of the two methods.
OAuth2 is a protocol that allows an application requests access token from the security token service and use them to communicate with the API. Since centralized authentication and authorization, so this reduces the delegated client applications and the complexity of the API.
OpenID Connect and OAuth 2.0 - better together
OpenID Connect and OAuth 2.0 are very similar - in fact, OpenID Connect is an extension OAuth 2.0. Authentication and API access to both basic security issues are combined into an agreement - usually only once and from a security token service.
We believe that the combination OpenID Connect and OAuth 2.0 is that in the foreseeable future, the best way to protect modern applications. IdentityServer4 is to achieve these two protocols, and is highly optimized to address today's move, the typical security problems native and Web applications.
How IdentityServer4 help
IdentityServer is compliant OpenID Connect and OAuth 2.0 endpoint added to any ASP.NET Core middleware applications.
Typically, you build (or reuse) containing login and logout page (may also require you to agree that - depending on your needs) applications, IdentityServer middleware will add the necessary agreements to which the head so that the client application can be dialogue those using standard protocols.
You can use the host application as complex as you need. However, in order to maintain the attack surface as small as possible, we generally recommend that you only authentication-related UI included.
Related Terms
IdentityServer
IdentityServer is a provider OpenID Connect - which implements the OpenID Connect and OAuth2 protocol.
For the same role, different documents will use different terms - you may also find a Security Token Service (Security Token Service), the identity provider (Identity Provider), authorization server (Authorization Server), IP-STS etc. . But they all have the same meaning: Some security tokens issued to the client software used.
IdentityServer contains some of the responsibilities and functions:
- Protect your resources
- Using a local account store or an external identity provider for user authentication
- Provides session management and single sign-on (Single Sign-on)
- Client Management and Certification
- To release the identity of the client token and access token
- Authentication token
user
End users who access the relevant data by registered customers.
Client
The client software is part of the request token from IdentityServer (Token) of - either to authenticate a user (ie, the request is identity token), can also be access to a resource (that is, the request is access token) . A client must first register in order to IdentityServer request related tokens.
The client can be a Web application, mobile client or desktop applications, single-page application (SPA, Single Page Application), server processes, and so on.
Resources
Resources are things you want to pass IdentityServer protection - can be both your user identity information may also be API.
Each resource has a unique name - clients use these names to specify the resources they want to access.
Identity data (Identity data) is a user's identity information (also known claims), such as name (name) and email address (email address).
API resource represents the function you want to call the client - usually through the Web API to model API resources, but this is not necessary.
Identity token
An identity token represents the output of the certification process. It is minimally identifies a user (which can also be referred to as a subset of the master identity information, text: Called the sub aka subject claim), also contains the certification and authentication type of user. Identity token can contain additional identification data.
Access token
Access token used to grant access to an API resources. Client requests access token is then directed API. The access token contains the client and the user (if provided any) information, API data access rights granted to them by the information.
Reference: http://docs.identityserver.io/