Source: https://fullstackmark.com/
Date: 2020-01-14
Building a robust security model within our applications is a critical step toward shipping the type of high-quality, high-value software solutions we strive to deliver to our customers and organizations.
Despite its importance, the topic of application security is met, by many of us with less enthusiasm and priority than other more exciting or seemingly higher-value areas of our project. Every project is different, but a couple of general factors that I believe contribute to this perception are:
The natural inertia of innovation is causing applications to expand in size and complexity.
To maximize market reach, we often want to make our apps available to users coming from just about anywhere: corporate networks, social sites like facebook and twitter along with anonymous guests from the internet.
On top of that, many apps must also be accessible on a variety of interfaces, the usual suspects being web browsers and mobile devices but this list is expanding to include a growing number of IoT-enabled devices and things like Smart TVs.
Further complicating all of this is the rise of distributed and microservice architectures on the backend which results in a much more complex software environment with many moving pieces.
Designing, implementing and testing a security approach that encompasses all of these different pieces and their interactions is no small task!
Security protocols, principles and best practices are not as widely shared and commonly understood by most of us as they should be.
Security is a vast and deep topic. This may be an education or awareness thing but I believe that even if we don’t identify as a security specialist within our primary developer roles there are some small steps we can begin to take to gain a better understanding of real-world security threats and the defensive coding techniques and practices we can use to protect against them. The OWASP Checklist is a great place to start with this.
In this guide, we’ll see how to work through some of these problem areas while learning about identity and access control using OpenID Connect and OAuth. We’ll implement the Implicit Grant OAuth flow and utilize these identity and authorization protocols by implementing IdentityServer4 as our OpenID Connect Provider and then using it to authenticate our Angular SPA client to authorize access to an independent ASP.NET Core Web API.
OIDC/OAuth authentication and authorization flow with Angular, ASP.NET Core and IdentityServer4.
OIDC/OAuth authentication and authorization flow with Angular, ASP.NET Core and IdentityServer4.
Note: Security specs and standards evolve over time and OAuth is no different. There is currently a proposal in place to move away from the Implicit Flow we’re utilizing in this guide in favor of the authorization code grant with Proof Key for Code Exchange (PKCE) to request access tokens from SPAs, as opposed to the original spec proposing the implicit grant for this scenario. This new recommendation is not the result of some gaping security hole in the implicit flow model but rather an improvement with the major difference being the exchange of the access token is removed from the browser URL and instead redeemed by the client application using an authorization code.