Although there are several articles on the internet on OAuth including the pages on http://www.oauth.net , I was unable to understand the concept behind OAuth by going through any one of those pages and instead kept wandering to several pages. Maybe, because I was impatient soul and wanted to land onto one page which could help me understand it all at just one page without me to wander another set of pages including image searches in Google for keyword “oauth” or “oauth authentication”. The only pages which matched my appetite is http://hueniverse.com/oauth/ . However, one has to patiently go through all of these pages to understand OAuth. This is quite an uphill task given our short attention span and impatience. Thus, I decided to put it all in one page and here it goes. Do let me know if you liked what I had to say about OAuth-based authentication.
Key Terminologies (One must understand it first!)
Following are some of the key terminologies one must understand before reading any articles or, looking at any images on OAuth on the internet.
- User (Resource Owner): User, also termed as resource owner, is the one who is asked permission by the client/consumer application to access their protected resources such as contact information, friends list, photos etc from other websites where user is hosting these resources. For example, an event management website asking its user, permission to access their Facebook friends list to import them in order to send them invites. In this example, user is the resource owner of friends list on Facebook and client application is event management website.
- Client (Consumer): Client or consumer application is the one which wants to access the users protected resources on another website.
- Server (Service Provider): Server or the service provider is the one which hosts the protected resources of the user and give access to the client or consumer website.
Real-world Use-Cases
Let’s look at some of the examples as following:
- Registration with Facebook/Twitter/Google Account: Many a website provides user with the option of using their Facebook, Twitter or Google account to register. This one is a classic example where the websites act as client application, Facebook/Twitter/Google acts as service provider and you act as the user/resource owner. In this example, the resource that the websites get access to are users’ personal information including his email address, first name, last name, birth date etc that the website (client/consumer application) stores in its database for future access.
- Managing Facebook/Twitter News Feed: HootSuite web application or mobile app wants to access the news feed from your Twitter and Facebook account. Here, HootSuite acts as client/consumer application, Twitter and Facebook acts as service provider and you act as a user or resource owner.
Why Oauth-based Authentication needed in the first place?
Oauth-based authentication has come into picture, primarily, to solve the problem associated with client/consumer applications asking their users to share their credentials including his username and password to access their data on another website. Remember those days when websites (for example, website A) used to ask our credentials of other websites (say, website B) to import our friends email addresses and send them invitation to register with the website (A). The problem used to be the users concern around the misuse of their credentials (website A).
This is the primary problem that is addressed using Oauth-based authentication where websites (such as website A) can access contacts information of a user from another websites (website B in above example) without user having to share their credentials.
Understanding Oauth with a Detailed Storyline
http://hueniverse.com/oauth/guide/workflow/
The page in this URL describes OAuth-based authentication with a story which is so very easy to understand. In the story, the user, Jane, allows photo-printing website (client application) to access her private photos from Flickr, the Oauth service provider.
What is OAuth-based Authentication?
OAuth-based authentication is a different model of authentication which allows users (Resource Owner) to authorize another web/mobile apps (Client Applications) to access their protected resources on host website (Service Provider).
Following diagram (Courtesy: Flickr, Yahoo) explains the flow around how a user authorizes a client application to access the photos (users’ protected resources) from Flickr, OAuth Service Provider.
- As user clicks on link/button on client/consumer application to acquire photos, the application first acquires a request token (temporary credentials) based on the its client credentials. Remember, the client applications has to get itself registered with OAuth service provider after which it receives the client username and secret which can also be termed as client credentials.
- With temporary credentials, the client application then redirects the user (resource/photo owner) to the Flickr website.
- User then enters his Flickr credential on Flickr website.
- Once validated, Flickr provides information about Client application trying to access his protected resources (photos) and asks whether he/she authorizes the client application for same.
- Once User authorizes, Flicks (OAuth Service Provider) marks the temporary credential as OAuth verifier and redirects back to client application.
- Client application, then, requests for two tokens – access and refresh token (OAuth 2.0).
- With access token, client application accesses the protected resources.
- In case, access token expires, client application can use refresh token to acquire new access token.
Fig: User Authorizing Client Application to Access Photos from Flickr (Courtesy, Flickr)
[adsenseyu1]
Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
- Agentic Reasoning Design Patterns in AI: Examples - October 18, 2024
- LLMs for Adaptive Learning & Personalized Education - October 8, 2024
- Sparse Mixture of Experts (MoE) Models: Examples - October 6, 2024
I found it very helpful. However the differences are not too understandable for me