In the previous video, the basic concepts of OpenID Connect were introduced.
Now let's look at the authentication flows available in OpenID Connect, and how id tokens
and user information are exchanged.
OpenID Connect defines three authentication flows:
The Authorization Code flow, the Implicit flow
and the Hybrid flow.
The Authorization Code and Implicit flows are based on the OAuth flows of the same name.
The main difference with OpenID connect is that an ID token is also issued.
As these OpenID Connect flows are based on the same OAuth flows, the types of applications
they are best suited for are also the same.
The Hybrid flow is a combination of the Authorization Code and Implicit flow.
In this flow the client can request ID tokens, access tokens, or both from the Authorization
endpoint, along with an Authorization code that can be exchanged at the token endpoint
for the remaining tokens.
It's useful in situations such as single sign on, for example, where the client application
needs to immediate use an identity token to access the user's identity.
It also uses an authorization code to request access, and refresh tokens to get long-lived
access to resources.
The Hybrid Flow offers more flexibility with this token flow.
But, it's less secure than the Authorization Code Flow because some tokens are exposed
directly to the User Agent.
Let's now look at these flows in more detail.
In the Authorization code flow, an end user accesses an application that requires the
user to authenticate.
After clicking login, the client application redirects the user agent, typically a browser,
to the authorization endpoint of the Identity Provider.
The user agent makes a GET request to the Identity Provider, passing the following information
received in the redirect: The Location of the Identity provider
authorization endpoint.
A Response Type set to code, indicating this is the authorization code flow.
The scope, which in this case is set to openID, email, and profile.
The Scope openID shows this is a request for OpenID Connect authentication and an ID token.
The email and profile portions of the scope show that this client is requesting access
to the end user's profile and email address.
The Client ID of the relying party registered with the Identity Provider.
The state, which is a value set by the relying to maintain state between the request
and the callback itself.
And finally the Redirect URI, which is the location to redirect the callback to
once authenticated.
The user is then directed to the Identity Provider's login screen, where they enter
their credentials.
The Identity Provider authenticates the user and asks for consent to the relying Party's
request to access their identity.
With consent given, the Identity Provider sends an authorization response message from
its authorization endpoint.
This redirects the user agent back to the relying party using the redirection URI
provided earlier.
This URI includes an authorization code and any local state provided by the client
earlier.
The relying party then makes a request for an ID token to the token endpoint by sending
the base64 encoded client ID and secret, the Authorization code, and the redirect URI.
The Identity provider authenticates the client using the client ID and secret, and validates
the authorization code and redirect URI.
If valid, the Identity Provider responds back with the ID token from the token endpoint.
The response also includes an access token and an optional refresh token.
The client validates the ID token, and if successful, the identity is proven.
Since the original scope request asked for profile and email address, the client sends
the access token to the UserInfo endpoint.
Once the Identity provider validates the access token, it returns the claims to the relying
party and the Authorization Code flow is complete.
In the Implicit flow, there're two possible scenarios.
In the ID token and Access Token scenario, the client application requests both an ID
and access token.
The access token is used to request additional claims from the UserInfo endpoint.
In the ID token only scenario, the client application requests just an ID token, and
requests that any additional user claims are sent within the ID token itself.
Let's first look at the ID token-only scenario.
After clicking login, the client application redirects the user agent to the authorization
endpoint of the Identity Provider.
Here in the redirect, Response Type is set to ID Token, indicating the implicit flow
and that we're requesting an ID Token only.
Additionally, a nonce value is set to mitigate replay attacks.
As before, the user logs in, and consent to access their identity is requested.
When the user gives consent, an Authorization Response message is sent from the Authorization
Endpoint, which redirects the user agent back to the client.
The redirection UR eye includes the ID Token in a URI fragment.
This ID token contains the standard claims, along with those from the profile and email
scopes.
As the ID token is returned in a UR eye fragment, the user agent needs to parse the fragment
encoded values and pass them on to the clients processing logic for consumption.
The User Agent needs to parse the ID token encoded values that were returned in the URI
eye fragment, and then pass them to the client's processing logic.
The user agent follows the redirect URI, but retains the ID token.
The application returns a webpage that contains a script.
The script can extract the ID token from the full redirect URI.
The user agent executes the provided script, and passes the extracted ID token to the client
application.
The client application validates the ID token, and now has proof of identity and all the
claims it requires.
In the ID Token and Access Token scenario, the flow is almost the same, except, in the
initial redirect we use Response Type equals id_token token.
After user authentication and consent, instead of just an ID token, the Identity Provider
also sends an access token in a UR eye fragment.
The client application extracts the ID token, and access token, and validates the ID token.
Because the ID token doesn't contain the profile claims, the access token is sent to
the UserInfo endpoint.
Once the access token is validated, the claims are returned to the application.
The Hybrid flow is a combination of the Authorization Code and Implicit flows.
Tokens can be returned by both authorization and token endpoints.
Where the tokens are returned from depends on the Response Type specified in the redirect
URI.
The Response Type can be set to either Code Token, Code ID Token, or Code ID Token Token.
If, for example, the client application chooses Code ID Token, the user agent redirects to
the identity provider passing the Response Type equals Code ID Token along with the scope
it requires.
The end user logs in and is asked for consent.
After consent is given, an Authorization message is sent, which redirects the user agent back
to the client application.
The redirection UR eye includes the authorization code, and ID token.
The ID token is validated the same way as described in the Implicit flow.
The authorization code is then sent to the token endpoint the same way as described in
Authorization code flow.
Once validated, the access token is sent back, along with another ID token.
This ID token is compared to the previous one for validation.
Because the client application requested scope equals openid profile, the access token is
sent to the UserInfo endpoint to retrieve the claims.
In this video, we looked at the different flows developers can choose from when enabling
client applications to use OpenID Connect.
We looked at how OpenID Connect allows client applications to verify an End Users identity,
and obtain basic profile information about that user using REST API's.
We also saw how OpenID Connect provides client applications with the when, where and how
the authentication occurred, and how it can be used to allow federated single sign on.
To learn more about cloud standards and protocols, please check out the other videos in this
series.
Thank you for watching.
For more infomation >> Sonocent for Mac Home Tab - Duration: 1:58. 
For more infomation >> Statens vegvesen - VR-dataspill for bedre plalegging - Duration: 0:37. 
Không có nhận xét nào:
Đăng nhận xét