The modern application looks like this:
Typical interactions include the following:
- The browser communicates with the Web application
- Web applications communicate with Web APIs (sometimes on their own, sometimes on behalf of users)
- Browser-based applications communicate with the Web Api
- Native applications communicate with the Web Api
- Server-based applications communicate with the Web Api
- Web APIs and Web APIs interact (sometimes on their own and sometimes on behalf of users)
Typically, each layer (front-end, middle-tier, and back-end) has the need to protect resources and perform authentication and authorization-typically for the same user store. This is why the business application/endpoint itself does not implement these basic security features, preferring to outsource to the security token service. This will have the following security architecture:
This requirement for security is divided into two parts.
Identity verification
Authentication is required when an application needs to know the identity of the current user. Typically these applications manage data on behalf of the user and need to ensure that the user can access only the data that he allows. The most common examples are (classic) Web applications--but native and JS-based applications are also required for authentication.
The most common authentication protocol is saml2p, ws-federation and OpenID connect--saml2p are the most popular and widely deployed authentication protocols.
OpenID Connect is the newest of the three, but is often considered the future direction because it has the most potential in modern applications. It was designed to be a friendly API for mobile applications from the start.
API Access
There are two basic ways for an application to communicate with the API, using the application's identity, or delegating the user's identity. Sometimes these two methods must be combined.
OAuth2 is a protocol that allows applications to request access tokens from the security token service and use them to communicate with the API. It reduces the complexity of the client application, as well as the API, because centralized authentication and authorization can be performed. OpenID addresses cross-site authentication issues, and OAuth addresses cross-site licensing issues. Authentication and authorization are inseparable. The two sets of protocols for OpenID and OAuth come from two different organizations with similarities and overlaps, so it's difficult to integrate them. Fortunately, OpenID Connect, as the next version of OpenID, expands on the OAuth 2.0 protocol, which is a good solution to the unity of authentication and authorization, and to the convenience of developers. Thinktecture Identityserver v3 is an open source OpenID Connect provider and OAuth2 authentication Server on a. NET platform.
Getting Started Tutorial:. NET open source OpenID Connect and OAuth Solutions identityserver v3 Introduction (i)