1 00:00:03,040 --> 00:00:10,030 Now let's talk about the support and ADF's 2019 for OAuth 2.0 Authorisation Flows in authentication 2 00:00:10,030 --> 00:00:17,200 with OpenID Connect oh off 2.0 is the base technology that defines the authorization flows. 3 00:00:17,910 --> 00:00:23,400 Olaf enables a third party application to gain access to a service on behalf of the resource owner, 4 00:00:23,400 --> 00:00:27,060 but it doesn't tell you who the user is that authorized the access. 5 00:00:27,720 --> 00:00:34,830 Open ID Connect extends OAuth flows by adding a few extra steps for secure authentication rather than 6 00:00:34,830 --> 00:00:42,030 using XML and soap for messaging like Feed and SAML, OAuth and Open ID, Connect, Use Rest and JSON. 7 00:00:42,690 --> 00:00:49,110 ADF's has supported OEF 2.0 since ADF's in Windows Server 2012 or two. 8 00:00:49,660 --> 00:00:56,080 But OpenID Connect support was only added in Windows Server 2016, and enhancements have since been 9 00:00:56,080 --> 00:00:58,360 added in Server 2019. 10 00:00:58,960 --> 00:01:04,090 Let's look at these technologies in terms of the three elements of an authentication flow. 11 00:01:04,690 --> 00:01:08,710 The sign in protocol in this case is open ID connect. 12 00:01:09,340 --> 00:01:13,720 The authentication protocol is whatever we can figure in ADF's. 13 00:01:14,370 --> 00:01:19,680 And the token type that's returned is a JavaScript web token or JWT. 14 00:01:20,280 --> 00:01:25,890 There's actually several types of tokens involved in the authentication and authorization steps. 15 00:01:26,520 --> 00:01:32,100 The first is an authorization token that the client can pass to an application in order for the application 16 00:01:32,100 --> 00:01:35,250 to call PDFs to retrieve an access token. 17 00:01:35,910 --> 00:01:40,980 You'll see in the explanation of the authorization flows shortly how and why this is done. 18 00:01:41,610 --> 00:01:46,740 The access token or bearer token is used to get access to a protected resource. 19 00:01:47,430 --> 00:01:53,580 Open ID Connect adds an ID token issued by DFES that contains claims that describe the user. 20 00:01:54,210 --> 00:02:01,230 Claims can be extracted from both the access and ID tokens, as you'll see in the demos for some authorization 21 00:02:01,230 --> 00:02:01,750 flows. 22 00:02:01,770 --> 00:02:07,620 There's also a refresh token issued that the client application can send to ADF's to refresh the access 23 00:02:07,620 --> 00:02:09,210 token, an ID token. 24 00:02:09,840 --> 00:02:15,570 Let's talk at a high level about the type of open ID connect and OAuth 2.0 authorization flows that 25 00:02:15,570 --> 00:02:17,370 are supported by ADF's. 26 00:02:18,150 --> 00:02:22,830 I'll go into more detail on a few of them that are used most often, but at a high level. 27 00:02:22,860 --> 00:02:25,470 ADF's supports the following flows. 28 00:02:26,130 --> 00:02:32,400 The implicit flow allows single page web applications like angular apps to retrieve an ID token and 29 00:02:32,400 --> 00:02:35,670 an authorization token to access server side resources. 30 00:02:36,330 --> 00:02:41,520 The authorization code flow allows a web app to sign end users, and it also allows a native client 31 00:02:41,520 --> 00:02:45,450 application to get an authorization code to access a web API. 32 00:02:46,050 --> 00:02:51,570 And you can also use the authorization code flow to give a web app delegated authorization to call a 33 00:02:51,570 --> 00:02:52,650 web API. 34 00:02:53,280 --> 00:02:58,890 This is called the on behalf of Flow and it's used on the Internet to allow a site to access your personal 35 00:02:58,890 --> 00:03:03,090 information on a social media site without having to pass your credentials. 36 00:03:03,750 --> 00:03:06,540 Adverse can follow a similar flow. 37 00:03:07,150 --> 00:03:12,820 The client credentials grant flow allows a client like a web server or a service to access web hosted 38 00:03:12,820 --> 00:03:19,750 resources using the identity of an application so it doesn't require the interaction of a user. 39 00:03:20,390 --> 00:03:23,900 It's more like using a service account behind the scenes. 40 00:03:24,500 --> 00:03:30,200 The resource owner password credentials flow is similar, but it allows the web app to call a web API 41 00:03:30,200 --> 00:03:32,030 using the user's credentials. 42 00:03:32,690 --> 00:03:38,330 This requires handling the user's password, so it should only be used when more secure flows can't 43 00:03:38,330 --> 00:03:39,140 be used. 44 00:03:39,770 --> 00:03:43,910 And the device code flow is new to ADF's 2019. 45 00:03:44,540 --> 00:03:50,000 It allows for situations where there's no user interface for the user to sign in and they need to visit 46 00:03:50,000 --> 00:03:52,040 a web page on another device. 47 00:03:52,670 --> 00:03:58,910 So when the situation of a smart TV, a printer or an Iot device, the user can go to their phone or 48 00:03:58,910 --> 00:04:00,260 a browser and log in. 49 00:04:00,890 --> 00:04:06,770 Then the original device, the Smart TV, for example, gets the access token and refresh tokens it 50 00:04:06,770 --> 00:04:08,270 needs behind the scenes. 51 00:04:08,900 --> 00:04:12,140 Let's look at a few of these scenarios in more detail. 52 00:04:12,800 --> 00:04:18,860 The on behalf of flow is used when a web application needs to access the API of another application. 53 00:04:19,460 --> 00:04:22,610 It starts when the web app needs to sign in the user. 54 00:04:23,270 --> 00:04:28,640 The middleware on your application server would be configured to know the endpoint in PDFs with the 55 00:04:28,640 --> 00:04:30,590 open ID connect information. 56 00:04:31,190 --> 00:04:37,280 So if the user has not signed in the application, redirects the user's browser to add VFS specifically 57 00:04:37,280 --> 00:04:42,830 to the authorized endpoint in ADF's passing information about the permissions it needs to acquire from 58 00:04:42,830 --> 00:04:43,580 the user. 59 00:04:44,240 --> 00:04:50,270 This is similar to the authentication flows you saw in the previous clip on US Federation and the SAML. 60 00:04:50,300 --> 00:04:55,130 Except of course, the parameters are different for the open ID Connect protocol. 61 00:04:55,730 --> 00:04:59,690 But also one of the parameters passed is something called the scopes. 62 00:05:00,350 --> 00:05:05,270 Scopes are the permissions the web app is requesting the user to grant access to. 63 00:05:05,900 --> 00:05:11,330 In this case, the Web app is requesting that it can act on behalf of the user when accessing the web 64 00:05:11,330 --> 00:05:12,200 API. 65 00:05:12,800 --> 00:05:19,070 When the user, agent or browser is redirected to ADF's, the user logs in using whatever authentication 66 00:05:19,070 --> 00:05:23,060 method is configured and all the claims policies are executed. 67 00:05:23,740 --> 00:05:29,860 A PDFs, returns the ID token and an authorization token, and the browser is redirected to the original 68 00:05:29,860 --> 00:05:34,540 application the user was trying to access, which can also access these tokens. 69 00:05:35,170 --> 00:05:41,860 The Web app on the server, then calls PDFs to retrieve the access token for the web API using the authorization 70 00:05:41,860 --> 00:05:43,960 token sent by the user's browser. 71 00:05:44,610 --> 00:05:50,460 The Web app receives the access token, which in OAuth terminology is a barrier token and it uses it 72 00:05:50,460 --> 00:05:53,580 to gain access to the information on the web API. 73 00:05:54,180 --> 00:05:59,190 This whole flow is very common on the web and it's one of the most used OAuth flows. 74 00:05:59,820 --> 00:06:05,340 When you're browsing a web application that wants to access information in your Facebook or Google accounts. 75 00:06:05,370 --> 00:06:08,700 The app redirects you to those apps to delegate access. 76 00:06:09,300 --> 00:06:15,660 So this is a standard delegation flow in OAuth that is supported by RFS when designing your applications. 77 00:06:16,320 --> 00:06:22,110 The on behalf of flow is a variation of the authorization code flow, which in its more basic form doesn't 78 00:06:22,110 --> 00:06:25,290 need to access another application or web API. 79 00:06:25,890 --> 00:06:31,530 The authorization flow performs the same steps, including retrieving an access token, but it doesn't 80 00:06:31,530 --> 00:06:35,160 use the access token to retrieve information from another site. 81 00:06:35,790 --> 00:06:40,950 In the case of a web application, signing and users, this seems like a redundant step. 82 00:06:41,430 --> 00:06:47,190 But when the client isn't a web app but a native desktop app, then the purpose of the access code is 83 00:06:47,190 --> 00:06:49,920 to gain access to the backend web API. 84 00:06:50,540 --> 00:06:52,280 It can be a bit confusing why? 85 00:06:52,280 --> 00:06:54,920 There are what seems like extra steps involved. 86 00:06:55,530 --> 00:07:00,780 But the way I look at it, these flows have been adapted to situations that would normally be sufficiently 87 00:07:00,780 --> 00:07:03,690 covered by Federation and the SAML. 88 00:07:04,350 --> 00:07:10,590 The Open ID Connect and OAuth flows are superimposed on top of those use cases, so we can use the protocols 89 00:07:10,590 --> 00:07:13,470 for all of our application development scenarios. 90 00:07:14,070 --> 00:07:17,130 So there may be steps that don't seem intuitive. 91 00:07:17,730 --> 00:07:23,280 You'll see the authorization code flow used in the demo where the web app uses OpenID Connect to sign 92 00:07:23,280 --> 00:07:30,210 in a user of the application in the previous flows, a refresh token can be retrieved which allows the 93 00:07:30,210 --> 00:07:35,850 application to periodically refresh the access token in order to keep accessing the resources. 94 00:07:36,450 --> 00:07:41,670 Now let's talk about the implicit flow, because this is used for single page applications that use 95 00:07:41,670 --> 00:07:45,570 a framework like Angular JS, Ember JS or react. 96 00:07:46,200 --> 00:07:52,380 In this flow, a JavaScript application can get tokens from ADF's without having to perform a credential 97 00:07:52,380 --> 00:07:56,070 exchange on the server back end in the request. 98 00:07:56,070 --> 00:08:01,620 The response type parameter is set to indicate that the single page application wants to get the access 99 00:08:01,620 --> 00:08:05,820 token right away from the authorization endpoint along with the ID token. 100 00:08:06,420 --> 00:08:11,790 Then the single page application can use the access token as a barrier token to access the back end 101 00:08:11,790 --> 00:08:14,070 resource, which is a web API. 102 00:08:14,670 --> 00:08:19,860 One of the drawbacks of the implicit grant flow is that it doesn't retrieve a refresh token, so you'll 103 00:08:19,860 --> 00:08:22,470 need to refresh these tokens periodically. 104 00:08:23,030 --> 00:08:27,860 But you can choose to only refresh either the ID token or the access token. 105 00:08:28,530 --> 00:08:33,810 I won't go into much more detail on OAuth and open ID connect, but I'll just highlight how flexible 106 00:08:33,810 --> 00:08:38,880 the protocol is by discussing some of the parameters you can pass in the initial request to the identity 107 00:08:38,880 --> 00:08:39,420 server. 108 00:08:39,420 --> 00:08:45,840 In our case, ADF's, there's a client ID that identifies the application in ADF's. 109 00:08:46,500 --> 00:08:52,650 The redirect, URI, is where you want the authentication response to be sent and received by your application. 110 00:08:53,250 --> 00:08:57,600 You also register this value in ad fs for your application. 111 00:08:58,190 --> 00:09:02,120 The response type parameter defines the type of flow being used. 112 00:09:02,780 --> 00:09:05,720 In this case, you would pass the value code. 113 00:09:06,320 --> 00:09:12,050 You can pass in some optional values also, including a list of scopes that describe the specific actions 114 00:09:12,050 --> 00:09:14,090 you're requesting authorization for. 115 00:09:14,790 --> 00:09:19,680 In order to get the user identity information, one of those scopes needs to be the value. 116 00:09:19,680 --> 00:09:26,640 OpenID And this is the standard way of requesting to use the OpenID Connect Authentication Protocol. 117 00:09:27,330 --> 00:09:33,030 There are other standard scopes defined in the OAuth protocol and you can define your own in ADF's. 118 00:09:33,700 --> 00:09:39,040 You can also use the response underscore mode parameter to indicate how you want the tokens returned 119 00:09:39,040 --> 00:09:45,640 and that can be as query string parameters in the redirect URI as a fragment in code or as forms parameters 120 00:09:45,640 --> 00:09:47,800 in a post to the redirect URI. 121 00:09:48,400 --> 00:09:54,280 Now in terms of how to configure ADF's for apps that you so often open ID connect, every OAuth client 122 00:09:54,280 --> 00:09:59,680 and resource needs to be associated with an application group in ADF's 2019. 123 00:10:00,310 --> 00:10:03,910 So in the next clip, let's examine application groups.