OAuth 2.0 explained with examples

lot was designed to allow third-party applications to access protected resources on behalf of a user it was a great improvement over traditional authentication methods such as username and password because it was more secure and flexible however worth 1.0 was complex and difficult to implement and it was not widely supported as traditional authentication methods in 2012 a new version of oauth was released called oauth 2.2 or 2.0 addressed many of the shortcomings of oauth 1.2 while also providing a number of new features and improvements today or 2.0 is used by a lot of websites and apps like Facebook Twitter and Amazon it's a safe and secure way to let websites access your data without sharing your password in other words or 2.0 is a protocol for sharing user authorization across systems in this video we'll explore the fundamental principles of oauth 1.0 and 2.0 including identity providers access tokens the four types of oauth's laws how it differs from authentication and its supports for Json web tokens by the end of this short video you will have a solid understanding of the or 2.0 ecosystem a Cornerstone for modern digital security so let's Dive In simply speaking or 2.0 is a way for two websites to talk to each other without sharing your password it works like this let's say you want to play a game on your computer but you need to log into your Google account to play it you don't want to give the game your password so you use or 2.0 instead the game websites ask you to log into your Google account you go to Google and login Google gives the games website a special code called access token the game website uses the access token to talk to Google and get your data and then you can play the game the access token is like the key that lets the game website talk to Google on your behalf it is a short-lived credential that allows an application to access a user's protected resources on behalf of the user it is not the user's password and it does not Grant the application full access to the user's account the access token is typically generated by an authorization server after the user has granted the application permission to access their resources the authorization server then Returns the access token to the application which can then use it to make requests to the resource server the access token is typically used in conjunction with the authorization header which is added to each request made to the resource server the authorization header includes the access token as well as the type of the token for example where a token and the tokens expiration type the resource server then validates the access token and if it is valid grants the application access to the requested resources here is an example of how an access token is used in the or2 authorization code flow the user visits the application website and clicks on a button to log in with Google the application redirects the user to the Google authorization server the Google authorization server asks the user to log in to their Google account the user enters the username and password and clicks the allow button the Google authorization server generates an access token and redirects the user back to the applications website the application receives the access token and stores it in its database the application uses the access token to make requests to Google's apis the access token is only valid for certain amount of time after which it expires where the access token expires the application will lead to obtain a new one from the authorization server access tokens are an important part of the oauth authorization framework they allow applications to access protected resources on behalf of users without having to share the user's password and this helps to protect the user's privacy and security the resource server is not explicitly mentioned in the flow but it is the entity that hosts the protective resources that the application wants to access in the example above the Google apis are the resource servers the resource server is not involved in the authentication or authorization process it simply evaluates the access token and if it is valid runs the application access to the requested resources the resource server can be implemented in different ways depending upon the specific use case for example the resource server can be web application a mobile application or a cloud service now I have covered durability in detail in my previous video where I explained how they are a great way to authorize users and perform role checks in front-end to backend communication and in distributed microservices architecture or 2.0 and JWT are two different protocols but they can work together to provide a secure and efficient way for third-party applications to access protected resources in the context of or 2.0 jwts can be used to represent access tokens this is because jwts are self-contained and can be easily verified by the resource server let's say you want to use a third party application to access your Google calendar the third party application first needs to obtain an access token from Google it does this by using or 2.0 to authenticate you with Google once you have authenticated Google will issue an access token to the third party application the third party application that takes the access token and encodes it has JWT the JWT is then sent to the resource server which is Google Calendar in this case the resource server can then verify the JWT and Grant the third party application access to your calendar the use of JWT is with or 2.0 provides a number of benefits jwts are self-contained and can be easily verified by the resource servers and this makes them more secure than other types of access token such as OPEC tokens jwts are also Compact and URL safe making them easy to transmit over the network and this can improve the performance of or 2.0 applications and finally jwts can be used to represent a variety of claims such as identity authorization or other data and this makes them versatile and adaptable to different use cases overall jwtas are a lightweight token format that can be used to transmit authorization information but they do not provide any authentication or authorization Services themselves whereas or 2.0 is an authorization framework that can be used to authenticate users and Grant them access to protected resources overall or 2.0 and JWT are two powerful protocols that can be used together to provide secure and efficient way for third-party applications to access protected resources also known as SSO or single sign-on in the example above I gave the Google authorization server is also Google identity provider it is the entity that authenticates the user and issues the access token this is because Google is large a trusted organization that can provide both authentication and authorization services however in other cases authorization server and identity provider may be separate entities for example a company might use a third party identity provider to authenticate its users and then use its own authorization server to Grant access to its protected resources the important thing to remember is that the authorization server and identity provider are two different roles in or 2.0 authorization framework the authorization server is responsible for issuing access tokens and the identity provider is responsible for authenticating users now in some or 2.0 flows these roles can be combined into a single entity but in other cases they may be separate entities so let's talk about flows there are four types of oauth 2 Data flows authorization code flow is the most common flow it is used when the application needs to access protected resources on behalf of the user the user first authenticates with the IDP and then the IDP redirects the user back to the application with an authorization code the application then sends authorization code to the authorization server which validates the code and returns an access token and a refresh token to the application the application can then use the access token to make requests to the resource server client credential flows is used when the application does not access protected resources on behalf of the user instead the application needs to access its own protected resources the application authenticates with the authorization server using its client ID and client secret and the authorization server returns an access token to the application the application can then use the access token to make requests to its resource server resource owner password flow is used when the application needs to access the user's protected resources but the user do not want to be redirected to the idb instead the application asks the user to enter the username and password directly into the application the application then sends the username and password to the authorization server which validates the credentials and returns an access token and a refresh token to the application the application can then use the access token to make requests to the resource server implicit flow is a simplified version of authorization code flow and in the implicit flow the authorization server redirects the user back to the application with an access token in the URL the application can then use the access token to make requests to the resource server the implicit flow is not as secure as the authorization code flow and it is not recommended for most applications the or 2.0 authorization framework provides a variety of flows to meet the needs of the different applications the best flow to use depends on the specific application and its requirements and there is no official or 3.0 specification yet but there are some proposals which are still in the early stages or 2.0 is currently the defactor standard for authorization in the world of web applications and it is likely to continue to evolve and improve in the years to come foreign [Music]

Channel: ByteMonk

Views: 69,098

Keywords: system design, interview question, faang, technology, system design tutorial, system design interview questions, system design interview, oauth 2.0, security, jwt, access tokens, idp

Id: ZDuRmhLSLOY

Length: 10min 2sec (602 seconds)

Published: Wed Sep 13 2023