OAuth 2.0 explained with examples - द्विभाषीय उपशीर्षक
OAuth 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, OAuth 1.0 was complex and difficult to implement, and it was not widely supported as possible.
traditional authentication methods.
In 2012, a new version of OAuth was released called OAuth 2.0.
OAuth 2.0 addresses many of the shortcomings of OAuth 1.0, while also providing a number of new features and improvements.
Today, OAuth 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, OAuth 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 apps.
goes, how it differs from authentication and it supports for JSON web tokens.
By the end of this short video, you will have a solid understanding of the OAuth 2.0 ecosystem, a cornerstone for modern digital security.
So...
Simply speaking, OAuth 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 OAuth 2.0.
The game website asks you to log in to your Google account, you go to Google and log in.
Google gives the game's 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 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 the user's 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 via a token, and the token's 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 O2 authorization code flow.
The user visits the application website and clicks on a button to log in.
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 enters the user name and password and clicks the allow button.
The Google authorization server generates an access token and redirects the user back to the application's website.
site.
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 a certain amount of time.
When the access token expires, the 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 protected resources that the application.
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 validates the access token, and if it is valid, grants application access to the requested resource.
The resource server can be implemented in different ways, depending upon the specific use case.
For the resource server can be web application, a mobile application, or a cloud service.
Now, I have covered JWT 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 back-end communication and in distributed microservices architecture.
War2.0 and JWT are two different ways.
but they can work together to provide a secure and efficient way for third-party applications to access protected resources.
In context of OAuth 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 OAuth 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 as a trigger.
The JWT is then sent to the resource server, which is Google Calendar in this case.
The server can then verify the JWT and run the third-party application access to your calendar.
The use of JWT is with OAuth 2.0,
provides a number of JWTs are self-contained and can be easily verified by the resource servers,
and this makes them more secure than other types of access tokens, such as opaque tokens.
JWTs are also compact and URL-safe.
making them easy to transmit over the network.
And this can improve the performance of OAuth 2.0 applications.
And finally, JWTs can be used to represent a variety of claims, such identity, authorization, or other data.
And this makes them versatile and adaptable to different use cases.
Overall, JWTs are a lightweight token format that can be used to transmit authorization information.
But they do not provide any authentication or authorization services.
Whereas, OAuth 2.0 is an authorization framework that can be used to authenticate users and grant them access to protected resources.
Overall, OAuth 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, 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 OAuth 2.0 authorization tree work.
The authorization server is responsible for issuing access tokens and the identity provider is responsible for authenticating users.
Now, in some OAuth 2.0 flows, these roles can be combined into a single but in other cases, they may be separate entities.
So, let's talk about flows.
There four types of OAuth 2.0 flows.
Authorization flow is the most common flow.
It is used when the application needs to access protected resources on behalf 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 request to the resource server.
Clend 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.
The 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 IDV.
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.
and a refresh token to the application.
The application can then use the access token to make a request 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 user.
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 OAuth 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 OAuth 3.0 specification yet, but there are some proposals which are still in the early stages.
OAuth 2.0 is currently the de facto standard for authorization in the world of web applications,
and it is likely to continue to evolve and improve in the years to come.
अधिक सुविधाओं को खोलें
ट्रांसी एक्सटेंशन स्थापित करें और अधिक सुविधाओं को खोलें, जैसे कि AI उपशीर्षक, AI शब्द परिभाषा, AI व्याकरण विश्लेषण, AI बोलना, आदि।
मुख्य वीडियो प्लेटफ़ॉर्म के साथ संगत
Trancy न केवल YouTube, Netflix, Udemy, Disney+, TED, edX, Kehan, Coursera जैसे प्लेटफ़ॉर्मों के लिए द्विभाषीय उपशीर्षक समर्थन प्रदान करता है, बल्कि नियमित वेब पृष्ठों के लिए शब्द / वाक्य अनुवाद, पूर्ण-पाठ तार्किक अनुवाद और अन्य सुविधाएं भी प्रदान करता है। यह एक सच्चा सभी-एक भाषा सीखने का सहायक है।
सभी प्लेटफ़ॉर्म ब्राउज़र का समर्थन
Trancy सभी प्लेटफ़ॉर्म ब्राउज़र का समर्थन करता है, इसमें iOS Safari ब्राउज़र एक्सटेंशन भी शामिल है।
विभिन्न दृश्य मोड
सारांश, पठन, मिश्रित और अन्य दृश्य मोडों का समर्थन करता है ताकि एक समग्र द्विभाषीय अनुभव हो सके।
विभिन्न अभ्यास मोड
वाक्य लेखन, वाणीक मूल्यांकन, बहुविकल्पी, वाक्य लेखन और अन्य अभ्यास मोडों का समर्थन करता है।
AI वीडियो सारांश
वीडियो को संक्षेप में देखने और महत्वपूर्ण सामग्री को तेजी से समझने के लिए OpenAI का उपयोग करें।
AI उपशीर्षक
केवल 3-5 मिनट में सटीक और तेजी से YouTube AI उपशीर्षक उत्पन्न करें।
AI शब्द परिभाषा
उपशीर्षक में शब्दों पर टैप करके परिभाषा देखें, AI-संचालित परिभाषाओं के साथ।
AI व्याकरण विश्लेषण
वाक्य व्याकरण का विश्लेषण करें ताकि वाक्यार्थ को तेजी से समझें और कठिन व्याकरण बिंदुओं को संभालें।
अधिक वेब सुविधाएं
द्विभाषीय वीडियो उपशीर्षक के अलावा, Trancy वेब पृष्ठों के लिए शब्द अनुवाद और पूर्ण-पाठ अनुवाद भी प्रदान करता है।