{"id":1474,"date":"2021-03-25T15:52:46","date_gmt":"2021-03-25T15:52:46","guid":{"rendered":"https:\/\/blog.samarthya.me\/wps\/?p=1474"},"modified":"2021-03-25T15:52:56","modified_gmt":"2021-03-25T15:52:56","slug":"oauth-2-0","status":"publish","type":"post","link":"https:\/\/blog.samarthya.me\/wps\/2021\/03\/25\/oauth-2-0\/","title":{"rendered":"oAuth: 2.0"},"content":{"rendered":"

What is OAuth?<\/h1>\n

From the official definition<\/a><\/p>\n\n\n

It is protocol for Authorization<\/p><\/blockquote><\/figure>\n\n\n\n

It allows authorization flows for web applications, desktop applications, mobile apps etc.<\/p>\n\n\n\n

\"\"
Protocol flow<\/figcaption><\/figure>\n\n\n\n

Key components<\/h2>\n\n\n\n

The 3 key components of OAuth are as under<\/p>\n\n\n\n

A. Roles\/Actors<\/h3>\n\n\n\n

oAuth RFC defines 4 roles<\/p>\n\n\n\n

1. resource owner <\/h4>\n\n\n\n

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. It can be a company as well.<\/p>\n\n\n\n

2. resource server <\/h4>\n\n\n\n

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. <\/p>\n\n\n\n

3. client<\/h3>\n\n\n\n

An application making protected resource requests on behalf of the resource owner and with its authorization<\/code><\/em>. The term “client” does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). <\/p>\n\n\n\n

\n

OAuth defines two client types, based on their ability to authenticate securely with the authorization server<\/code> (i.e., ability to maintain the confidentiality of their client credentials): <\/p>\n\n\n\n

confidential <\/h4>\n\n\n\n

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means. <\/p>\n\n\n\n

public <\/h4>\n\n\n\n

Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.<\/p>\n\n\n\n

\"\"\/<\/figure>\n<\/div><\/div>\n\n\n\n

4. authorization server <\/h4>\n\n\n\n

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization<\/code>.<\/p>\n\n\n\n

B. Scopes and Consent<\/h3>\n\n\n\n

Scopes is what you see when you are shown a confirmation dialog while requesting service from a provider that initiates the flow. These are coded by the application developer when writing the application. Scopes decouple authorization<\/code> policy decisions from enforcement<\/code>.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

C. Tokens<\/h3>\n\n\n\n

To request an access token, the client obtains authorization<\/code> from the resource owner<\/code>. The authorization is expressed in the form of an authorization grant<\/code>, which the client uses to request the access token<\/code>. OAuth defines four grant types: <\/p>\n\n\n\n