OAuth2 and OpenID Connect Strategies for AngularJS and ASP.NET

When you're building an Angular or ASP.NET MVC-based application, sooner or later you'll want to secure it - preferably sooner rather than later. In this course, you'll learn how OAuth2 and OpenID Connect, today's widely-used standards, can help you with that.
Course info
Rating
(264)
Level
Intermediate
Updated
Dec 21, 2015
Duration
4h 9m
Table of contents
Introduction
Understanding OAuth 2.0 Basics
Authorizing Access to the API
Understanding Identity: OpenID Connect
Working with OpenID Connect on the Client
Impersonating the User When Accessing the API
Advanced Topics
Dealing with Credentials
Description
Course info
Rating
(264)
Level
Intermediate
Updated
Dec 21, 2015
Duration
4h 9m
Description

A typical application these days consists of (at least) a client application and an API. In this practical, demo-driven course, you'll learn how to work with authorization and authentication using today's widely-used standards: OAuth2 and OpenID Connect. The focus of this course is security, both for Angular and ASP.NET MVC-based applications, but it aims to go beyond that. Amongst other things, we'll look into finding a safe way to get identity-related information in your application over impersonation when accessing an API, right up to dealing with credentials and two-factor authentication.

About the author
About the author

Kevin Dockx is a freelance solution architect (mobile/web), author & consultant, living in Antwerp (Belgium).

More from the author
Building an Async API with ASP.NET Core
Intermediate
2h 42m
Aug 14, 2018
More courses by Kevin Dockx
Section Introduction Transcripts
Section Introduction Transcripts

Authorizing Access to the API
Hi and welcome to the Authorizing Access to the API module from the OAuth 2. 0 and OpenID connect strategies for Angular and ASP. NET course at Pluralsight. My name is Kevin and I'll guide you through the rest of this module. In this module we'll dive into a lot of code, checking out the different means of getting authorized and where and how they fit best. We're working with OAuth 2. 0, which is for research authorization, ie authorizing access to our API. So that's exactly what we're do in this module and we'll do that by looking at the user cases specific flows are designed for and by implementing them where it makes sense. Note that this is not yet about logging into the client application, ie about securing the client. That is not what OAuth 2. 0 is for. That's what we'll tackle once we get to the OpenID connect modules. The first way to achieve authorization is through the client credentials flow. This one is used for machine to machine communication, so it's without an end user being involved. There's no user name or password, but there are client credentials, the client ID and client secret that can be exchanged for an access token. Because of that, this flow should only be used by confidential clients, like our MVC application, not by the Angularjs application as that cannot safely store that client secret. If we look at the flow in a bit more detail, you see it's a very simple one. First, the client authenticates with the authorization server by providing its client ID and client secret. He then requests an access token from the token endpoint at the authorization server. Then the authorization server authenticates the client and if valid, issues an access token. The MVC app is still a good candidate for this. Let's try this one out with a demo.

Understanding Identity: OpenID Connect
Hi and welcome to the understanding identity OpenID connect module from the OAuth 2. 0 and OpenID connect strategies for Angular and ASP. NET course at Pluralsight. My name is Kevin and I'll guide you through the rest of this module. This is a short purely theoretical module, but nevertheless a very important one. After having dived into our two for resource authorization, it's now time to look into that other thing most apps need, authentication, ie signing into the app. You shouldn't use an OAuth 2. 0 token to sign into an application, OAuth 2. 0 says nothing about the end user. The correct identity isn't guaranteed. And related to authentication often an application also wants access to identity related information, like give a name and address. These concerns are tackled by OpenID connect. OpenID connect is a simple identity layer on top of the OAuth 2. 0 protocol. It allows clients to verify the identity of the end user based on the authentication performed by an authorization server. As well as to obtain basic profile information about the end user and interoperable and a REST like manner. The core OpenId connect functionality is just authentication built on top of OAuth 2. 0. So it extends OAuth 2. 0. That's why we can't just start with OpenID connect, we first needed to learn about OAuth 2. 0 as this is just an extension of that. And next to that, it also allows for the use of claims to communicate information about the end user. If you want to have a look at the spec, you can find it at the link on the screen. So these days, and for most apps, when you're working with OAuth 2. 0, you're probably going to want to work with OpenID connect as well. Because it extends OAuth 2. 0 it still has all the authorization abilities of OAuth 2. 0 and as said, adds authentication and user info.

Working with OpenID Connect on the Client
Hi and welcome to the Working with OpenID Connect on the Client module from the OAuth 2. 0 and OpenID Connect strategies for Angular and ASP. NET course at Pluralsight. My name is Kevin and I'll guide you through the rest of this module. After the previous theoretical module, it's now time to start to dive into code. But we'll have to start by choosing the correct flow for the correct use case. Then again, choosing might be the wrong choice of words in this case, because the flow that's used for authentication depends on the response type we request. The authorization code flow returns an authorization code to the client which can now exchange it for an ID token and an access token directly. It also includes client authentication and it's suitable for clients that can securely maintain a client secret between themselves and the authorization server. So the same rules as with OAuth 2. 0 apply. Then we have the implicit flow, this is mainly used by clients implemented in a browser using a scripting language. Or native clients on mobile devices. The access token and ID token are returned directly to the client which may expose them to the end user and applications that have access to the end users users agent. The authorization server does not perform client authentication in this case. And the last one, the hybrid flow, well that's by far the one that's used most often for server-side apps like our ASP. NET MVC app, ie for confidential clients. It can return an authorization code and ID token, and authorization code and an access token or an authorization code and ID token and an access token. But what about public clients like Angular? Well as the hybrid flow needs to be able to safely store secrets, that's not advised. A way around this could be to send the authorization code to the server for example when you need a refresh token, we'll learn about that later on, and to request a token from there. We're going to use both the hybrid flow and the implicit flow in the upcoming demos.

Impersonating the User When Accessing the API
Hi and welcome to the Impersonating the User When Accessing the API module from the OAuth 2. 0 and OpenID Connect strategies for Angular and ASP. NET course at Pluralsight. My name is Kevin and I'll guide you through the rest of this module. In the previous module, we learned how we can leverage OpenID Connect for client level authentication and getting identity related information on the client. But when accessing the API, we haven't worked with the user related claims at that level yet. In the authorizing access to the API module we use the gallery managements scope to block or allow access to the API and care of the API is free for all. So we left something out. We haven't talked about impersonating the user yet, that's what this module is about. We're going to impersonate the user when accessing the API through the access token that's sent to the API on each request. Instead of only using the gallery management scope for authorizing access, wouldn't it be nice if we could work with user related claims, like a user's role, for example, at API level. And if we now know who the user is, who's accessing the API, we can ensure he has access to those items he or she should have access to and can only delete a picture he created. This is not something you want to do when calling the API from the client by passing in the ID as a parameter. It's something you want to handle at API level. And to allow for something like this, we'll have to ensure the access token contains the claims we need. Let's give that a try.

Dealing with Credentials
Hi and welcome to the Dealing with Credentials module from the OAuth 2. 0 and OpenID Connect strategies for Angular and ASP. NET course at Pluralsight. My name is Kevin and I'll guide you through the rest of the module. As we know by now, a user authenticates or inputs his credentials against a security token service, identity server in our case, not against the apps themselves. The applications use identity tokens provided by the STS to authenticate. Currently we're working with in memory users, that's not very realistic. You'll typically have your own user store where you're want to store these credentials. But you might also want to integrate identity server with external identity providers. This can be Facebook, Microsoft, Google, etc. But it might also be a WS federation supporting security token service. A lot of companies already have this, possibly using Windows credentials to authenticate against. We'll look into all of these in this module and we'll also learn how we can customize the login flow so we can, for example, ask for the user to input additional information needed for registration. Next to that, we'll also cover two factor authentication. Thanks to the fact that we've separated out checking off user credentials to the STS, the majority of the code we'll write in this module lives at the level of identity server. All of these demos will work for both the Angular and MVC applications and we'll very rarely have to change code in the client applications themselves. Let's kick off this module by replacing our in memory users with a custom user store.