OAuth 2.0 & OpenID Connect (OIDC): Technical Overview

hi and welcome to this OAuth 2.0 and open id connect overview video my name is peter bjork and i'm a principal architect at vmware if you haven't yet watched my other videos about identity and access management as well as my overview of the saml protocol i highly recommend watching them as well you find links to the videos here in the top right corner let's start by having a look at OAuth 2.0 while there exists earlier versions of OAuth it is version 2.0 that is being used today the OAuth protocol is not designed for handling user authentication and not really for authorization either so what is it designed for well it is really designed to provide delegated authority let me explain let's say you as a user of two applications wants to share data between them since your data is protected behind your login you would have to provide your credentials to 2 into application 1. doing so has many drawbacks application 1 would now have access to all your data you cannot decide what data should be accessible and what wouldn't it would also make changing password in application 2 harder you would have to not only change the password in app 2 but also remember to update it in app 1 and any other places where you have integration configured and of course providing your username and password to a third party is never a good idea and this use case is exactly what a wealth is designed to solve using OAuth 2.0 when you tell app 1 that you want to integrate it with application 2. it will trigger an OAuth 2.0 flow where you as a user logs in to app 2 and within app 2 approves the integration this means app1 never sees your password and you as a user can review the level of access app one is requesting before approving the integration and once approved an access token stamped with the access level is used by app1 to retrieve data from application 2. OAuth 2.0 offers many benefits over sharing your credentials with a third-party application you can verify and many time also change the level of access you grant another application you can easily change your password without breaking any integrations you can revoke access by simply deleting the access token and of course you do not need to share your password with anyone to summarize OAuth 2.0 allows you to grant authority to an application so the application can act on your behalf looking at the OAuth 2.0 standard you have four parties the resource owner the user who owns the data you have a client to whom you delegate authority you have the authorization server generating the access tokens and lastly the resource server where the user's data resides the authorization and resource server can be hosted on the same server or being completely separate companies can run a central authorization server providing access tokens for all their applications let's move on to a common implementation of OAuth 2.0 here you have installed a native application outlook in this example the backend is office 365 which hosts both the authorization server and the resource server when you launch the client for the very first time it connects to the backend but since outlook doesn't present a valid access token it must first obtain one from the authorization server redirected to the authorization server the user must somehow authenticate into office 365. this step of authentication is outside OAuth 2.0 and could be handled by something like saml but once authenticated the authorization server generates two tokens the access token and the refresh token both tokens are sent to the client and now the client attaches the access token to its request to the resource server and is allowed access to the user's data in this example email contacts and so on with the access token the outlook client can now check emails and perform other tasks on behalf of the user without the user having to type in its credentials all the time the user has delegated authority to the outlook client the credentials are not stored in the client and let's say the laptop gets stolen the user or an admin could revoke the client's tokens within office 365 blocking future access the time to live of the access and refresh tokens varies but often i see access tokens being valid for one hour and the refresh token has a range of time to live where idle time out meaning if the user hasn't used the application is set to 14 days but if the user uses the application daily the refresh token can have a valid time to live of 90 days which is a quarter or even longer so let's say an hour has passed so the initial access token has expired now the client uses the refresh token to request a new access token from the authorization server and as long as the refresh token is valid a new access token is issued this request for a new access token is completely seamless to the user you can argue that a ttl of 90 days is way too long which means 90 days before requiring a user to re-authenticate themselves to the system luckily many applications do allow the administrator to specify a lower time to live value a native client using OAuth 2.0 like in this example is very common nowadays and becomes more and more common with the spread of single sign-on and federation but where OAuth 2.0 is also very common is in server-to-server communication very much like my initial example of delegated authority in this example we have app one and two application one is the client in the OAuth flow and app2 is both the authorization and resource server but before any users of app1 can integrate it with app2 data the admins of each application must talk to each other the admin of app1 registered his or her application in app2 providing a name or identifier of the application and what callback url or redirect uri to send tokens to the admin of application 2 generates a client id and secret that application 1 should use in its communication with app2 very much like a username and password the client id and secret can of course be generated automatically via the configuration web page of app2 with this initial setup being done the resource owner or user can start the flow of adding integration between the two applications the flow starts with the user's web browser getting redirected with the message containing the client id of application 1 its redirect uri and response type in other words what is it application 1 wants in this case it is an authorization code so app1 can get an access token but app1 must also specify the scope for the authorization code the scope is what level of access to the resource owner's data is being requested in this example app1 wants access to the user's profile and its contacts the user's browser is now connected to application 2 and if not yet authenticated the user must log in but again this is not a part of the OAuth 2.0 standard what happens next is one of my favorites within the OAuth 2.0 flow the user is now presented with the scope and many times the user can actually change the level of access granted for example only allowing read access to context and not read and write access if the user approves or gives his or her consent to the scope negotiation an authorization code is generated and sent back to application 1 via the user's browser application 1 takes this authorization code and sends it directly to app2 together with its client id and secret specifying it wants to exchange the authorization code with an access token the authorization server of app2 generates and sends the access token to application 1. the access token is typically limited in time to live and is of the type bearer which means anyone with a token can use it now application 1 has an access token allowing it to access the resource owner's data and the access token is stamped with the privileges or scope of data access the access token is used to authorize each api calls application 1 since to application 2. but you may ask yourself why this dance involving first an authorization code and the exchange of it for an access token well it all boils down to security the initial steps of the flow were done with the help of the user's browser this is often referred to as front channel communication meaning the information could potentially be picked up by let's say a malicious code running within the browser itself if we would send the access token via the front channel and since it is of type bearer someone could steal the access token and access your data without our consent therefore the exchange for an access token is done server to server using what is referred to as a back channel if someone would get hold of the authorization code and trying to exchange it to a valid access token the request would fail since the client secret is not known to anyone but app 1 and 2 in this example or i would rather say the client secret must not be known to anyone else but app 1 and 2. so using the back channel and the client secret we should have a good confidence the access token is only delivered to the correct client we could of course add refresh token to the mix if we wanted but in this example i wanted to keep it simple this flow that i just covered is called the authorization code grant or flow and it makes use of both front channel and back channel the most commonly used flow for native clients is the authorization code flow with pixi or proof key for code exchange with a native client we cannot really store a secret securely but using pixi and its code challenge we can still establish trust between the client and the and there are many many more flows in OAuth 2.0 like the implicit flow for example only making use of front channel communication talking about many variations the token format in OAuth 2.0 isn't specified in the standard so it only says it should be a string value so we have a wide range of different token formats being used which of course complicates integrations between different vendor systems luckily json web token or jwt or jot as it's often pronounced is increasingly becoming the defacto standard another thing not specified within the standard is the scope while you often see things like profile it is up to each vendor to make up their own scopes and how granule its scopes should be OAuth 2.0 is very developer friendly and not having a very strict standard has allowed people to misuse it for example there have been implementations of OAuth 2.0 using it for user authentication which never was the use case covered by the standard to deal with this and to add a standard method of providing user authentication open id connect was created open id connect often called oidc is a standard added on top of OAuth 2.0 openid connect requires OAuth 2.0 and it adds that much requested standardization of providing user authentication openid connect adds a couple new things to the mix first it adds an id token which must be a jot and the standard specifies what claims can and should be within the id token it adds something called a user info endpoint and very much like the metadata in saml making it easier to establish integration and trust there is an open id connect discovery helping out with the configuration of the integration let's have a closer look at the open id connect flow we have our two applications where one is the client but since it's now also relying on a claim for user authentication it is also a relying party then we have app2 being the openid connect provider in this example it has also the new user info endpoint service running on it when the user tries to access app 1 app1 redirects the user to the configured open id connect provider for authentication this is done with a redirect message very much like in our original OAuth 2.0 flow but with one additional scope the open id1 the user authenticates into the provider and an authorization code is sent back to the application 1. app1 sends the authorization code via back channel to the provider and receives not only an access token but also an id token the id token contains some claims about the user such as the subject uniquely identifying the user but all the information about the user isn't sent in the id token id tokens should stay small if the relying party requires more information about the user it makes use of its access token and connects to the user info endpoint to retrieve more user data and attributes and that my friends was an overview of OAuth 2.0 and openid connect I hope you found this video useful if you are interested in more technical content please make sure to visit techzone.vmware.com

Channel: VMware End-User Computing

Views: 28,068

Rating: 4.940701 out of 5

Keywords: OAuth, OAuth 2.0, Overview, Basics, AccessICM, Module 9.4

Id: rTzlF-U9Y6Y

Length: 16min 19sec (979 seconds)

Published: Wed Sep 23 2020