Now let's talk about the support and ADF's 2019 for OAuth 2.0 Authorisation Flows in authentication
with OpenID Connect oh off 2.0 is the base technology that defines the authorization flows.
Olaf enables a third party application to gain access to a service on behalf of the resource owner,
but it doesn't tell you who the user is that authorized the access.
Open ID Connect extends OAuth flows by adding a few extra steps for secure authentication rather than
using XML and soap for messaging like Feed and SAML, OAuth and Open ID, Connect, Use Rest and JSON.
ADF's has supported OEF 2.0 since ADF's in Windows Server 2012 or two.
But OpenID Connect support was only added in Windows Server 2016, and enhancements have since been
added in Server 2019.
Let's look at these technologies in terms of the three elements of an authentication flow.
The sign in protocol in this case is open ID connect.
The authentication protocol is whatever we can figure in ADF's.
And the token type that's returned is a JavaScript web token or JWT.
There's actually several types of tokens involved in the authentication and authorization steps.
The first is an authorization token that the client can pass to an application in order for the application
to call PDFs to retrieve an access token.
You'll see in the explanation of the authorization flows shortly how and why this is done.
The access token or bearer token is used to get access to a protected resource.
Open ID Connect adds an ID token issued by DFES that contains claims that describe the user.
Claims can be extracted from both the access and ID tokens, as you'll see in the demos for some authorization
flows.
There's also a refresh token issued that the client application can send to ADF's to refresh the access
token, an ID token.
Let's talk at a high level about the type of open ID connect and OAuth 2.0 authorization flows that
are supported by ADF's.
I'll go into more detail on a few of them that are used most often, but at a high level.
ADF's supports the following flows.
The implicit flow allows single page web applications like angular apps to retrieve an ID token and
an authorization token to access server side resources.
The authorization code flow allows a web app to sign end users, and it also allows a native client
application to get an authorization code to access a web API.
And you can also use the authorization code flow to give a web app delegated authorization to call a
web API.
This is called the on behalf of Flow and it's used on the Internet to allow a site to access your personal
information on a social media site without having to pass your credentials.
Adverse can follow a similar flow.
The client credentials grant flow allows a client like a web server or a service to access web hosted
resources using the identity of an application so it doesn't require the interaction of a user.
It's more like using a service account behind the scenes.
The resource owner password credentials flow is similar, but it allows the web app to call a web API
using the user's credentials.
This requires handling the user's password, so it should only be used when more secure flows can't
be used.
And the device code flow is new to ADF's 2019.
It allows for situations where there's no user interface for the user to sign in and they need to visit
a web page on another device.
So when the situation of a smart TV, a printer or an Iot device, the user can go to their phone or
a browser and log in.
Then the original device, the Smart TV, for example, gets the access token and refresh tokens it
needs behind the scenes.
Let's look at a few of these scenarios in more detail.
The on behalf of flow is used when a web application needs to access the API of another application.
It starts when the web app needs to sign in the user.
The middleware on your application server would be configured to know the endpoint in PDFs with the
open ID connect information.
So if the user has not signed in the application, redirects the user's browser to add VFS specifically
to the authorized endpoint in ADF's passing information about the permissions it needs to acquire from
the user.
This is similar to the authentication flows you saw in the previous clip on US Federation and the SAML.
Except of course, the parameters are different for the open ID Connect protocol.
But also one of the parameters passed is something called the scopes.
Scopes are the permissions the web app is requesting the user to grant access to.
In this case, the Web app is requesting that it can act on behalf of the user when accessing the web
API.
When the user, agent or browser is redirected to ADF's, the user logs in using whatever authentication
method is configured and all the claims policies are executed.
A PDFs, returns the ID token and an authorization token, and the browser is redirected to the original
application the user was trying to access, which can also access these tokens.
The Web app on the server, then calls PDFs to retrieve the access token for the web API using the authorization
token sent by the user's browser.
The Web app receives the access token, which in OAuth terminology is a barrier token and it uses it
to gain access to the information on the web API.
This whole flow is very common on the web and it's one of the most used OAuth flows.
When you're browsing a web application that wants to access information in your Facebook or Google accounts.
The app redirects you to those apps to delegate access.
So this is a standard delegation flow in OAuth that is supported by RFS when designing your applications.
The on behalf of flow is a variation of the authorization code flow, which in its more basic form doesn't
need to access another application or web API.
The authorization flow performs the same steps, including retrieving an access token, but it doesn't
use the access token to retrieve information from another site.
In the case of a web application, signing and users, this seems like a redundant step.
But when the client isn't a web app but a native desktop app, then the purpose of the access code is
to gain access to the backend web API.
It can be a bit confusing why?
There are what seems like extra steps involved.
But the way I look at it, these flows have been adapted to situations that would normally be sufficiently
covered by Federation and the SAML.
The Open ID Connect and OAuth flows are superimposed on top of those use cases, so we can use the protocols
for all of our application development scenarios.
So there may be steps that don't seem intuitive.
You'll see the authorization code flow used in the demo where the web app uses OpenID Connect to sign
in a user of the application in the previous flows, a refresh token can be retrieved which allows the
application to periodically refresh the access token in order to keep accessing the resources.
Now let's talk about the implicit flow, because this is used for single page applications that use
a framework like Angular JS, Ember JS or react.
In this flow, a JavaScript application can get tokens from ADF's without having to perform a credential
exchange on the server back end in the request.
The response type parameter is set to indicate that the single page application wants to get the access
token right away from the authorization endpoint along with the ID token.
Then the single page application can use the access token as a barrier token to access the back end
resource, which is a web API.
One of the drawbacks of the implicit grant flow is that it doesn't retrieve a refresh token, so you'll
need to refresh these tokens periodically.
But you can choose to only refresh either the ID token or the access token.
I won't go into much more detail on OAuth and open ID connect, but I'll just highlight how flexible
the protocol is by discussing some of the parameters you can pass in the initial request to the identity
server.
In our case, ADF's, there's a client ID that identifies the application in ADF's.
The redirect, URI, is where you want the authentication response to be sent and received by your application.
You also register this value in ad fs for your application.
The response type parameter defines the type of flow being used.
In this case, you would pass the value code.
You can pass in some optional values also, including a list of scopes that describe the specific actions
you're requesting authorization for.
In order to get the user identity information, one of those scopes needs to be the value.
OpenID And this is the standard way of requesting to use the OpenID Connect Authentication Protocol.
There are other standard scopes defined in the OAuth protocol and you can define your own in ADF's.
You can also use the response underscore mode parameter to indicate how you want the tokens returned
and that can be as query string parameters in the redirect URI as a fragment in code or as forms parameters
in a post to the redirect URI.
Now in terms of how to configure ADF's for apps that you so often open ID connect, every OAuth client
and resource needs to be associated with an application group in ADF's 2019.
So in the next clip, let's examine application groups.