{"componentChunkName":"component---src-pages-markdown-remark-fields-slug-js","path":"/engineering/oauth2/","result":{"data":{"markdownRemark":{"id":"df511249-12dd-584f-8b40-3a1e682951ad","excerpt":"Getting Started with OAuth 2.0 OAuth has been a jargon for quite some time now and it is difficult for a beginner to learn it, not because OAuth is hard, but…","html":"

Getting Started with OAuth 2.0

\n

OAuth has been a jargon for quite some time now and it is difficult for a beginner to learn it, not because OAuth is hard, but because of the confusing facts found about OAuth on the web. So I wrote this article to explain why and how OAuth is used in very simple terms.

\n

Let’s start with the basics: OAuth stands for Open Authorization. It’s a process through which an application or website can access private data from another website.\nIt provides applications the ability for “secure designated access.” For example, you can tell Google that it’s OK for abc.com to access your google account or contact without having to give abc.com your google password.

\n

OAuth never share password data but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

\n

Now Let’s have a look at OAuth 2.0 Terminology.

\n\n

We have a pretty good understanding of OAuth 2.0 and Terminology, let’s move further and discuss the OAuth grant type that is widely used in this protocol.

\n

In total, there are five different grant type flows defined and described to perform authorizations tasks. Those are

\n\n

Authorization Code Grant

\n

The Authorization Code Grant Type is the most commonly used grant type.

\n

\n \n \n

\n

The Story: A user tries to log in on abc.com but he can’t remember his password and he discovers an option to sign in with google, by clicking on this, the user will easily get logged using google account.

\n

Flow

\n

The client redirects the user to the authorization server having the following parameters in the query string.

\n

Step 1

\n\n

After successful authentication, the user will be redirected to the Consent screen where he needs to provide consent to abc.com to access the account detail.\nAuthorization code is generated by the authorization server and sent back to the client with redirect Uri.

\n

Step 2\nThe client will now send a POST request to the authorization server with the following parameters:

\n\n

In the entire flow, the access token is never exposed to a web browser.

\n

Implicit Grant

\n

The Implicit flow was a simplified OAuth flow previously recommended for client-side applications like JavaScript apps where the access token was returned immediately without an extra authorization code exchange step.

\n

\n \n \n

\n

The Story: In this flow abc.com directly get access token without an extra authorization code exchange steps and able to access resources on a resource server

\n

Flow

\n

The client will redirect the user to the authorization server with the following parameters in the query string:

\n\n

It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.

\n

Resource Owner Credentials Grant

\n

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

\n

This grant type is suitable for clients capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.

\n

Flow

\n

The client will ask the user for their authorization credentials (usually a username and password).\nThe client then sends a POST request with following body parameters to the authorization server:

\n\n

Client Credentials Grant

\n

Using this flow the client can request an access token using only its client credentials (or other supported means of authentication).

\n

\n \n \n

\n

The Story: The client application presents its client credentials (client identifier and client secret) to the authorization server requesting approval to access the protected resource (owned by the client application) on the resource server.\nThe authorization server authenticates the client credential and issues an access token.

\n

Flow

\n

The client sends a POST request with following body parameters to the authorization server:

\n\n

Refresh Token Grant

\n

Access tokens eventually expire, however, some grants respond with a refresh token which enables the client to refresh the access token.

\n

Flow

\n

The client sends a POST request with following body parameters to the authorization server:

\n\n

Conclusion

\n

I hope you got an idea of how OAuth works and why it is needed. Now it’s time for you to go explore, find out more about the OAuth flow and implement it into your application.\nGood Luck and have fun! Thank you for following this article and hope it helped you! Please do buzz me if you want any help: indrasen.kumar@loginradius.com

\n","headings":[{"value":"Getting Started with OAuth 2.0","depth":1},{"value":"Now Let’s have a look at OAuth 2.0 Terminology.","depth":3},{"value":"Authorization Code Grant","depth":3},{"value":"Implicit Grant","depth":3},{"value":"Resource Owner Credentials Grant","depth":3},{"value":"Client Credentials Grant","depth":3},{"value":"Refresh Token Grant","depth":3},{"value":"Conclusion","depth":2}],"fields":{"slug":"/engineering/oauth2/"},"frontmatter":{"metatitle":null,"metadescription":null,"description":"Using this blog one can easily understand the basic concept of Oauth 2.0","title":"Getting Started with OAuth 2.0","canonical":null,"date":"August 24, 2020","updated_date":null,"tags":["Engineering","Oauth","Authentication"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.7699115044247788,"src":"/static/e6413c80a3d38d63b14543319d3c54dd/03979/oauth2.png","srcSet":"/static/e6413c80a3d38d63b14543319d3c54dd/f5f11/oauth2.png 200w,\n/static/e6413c80a3d38d63b14543319d3c54dd/6d133/oauth2.png 400w,\n/static/e6413c80a3d38d63b14543319d3c54dd/03979/oauth2.png 800w,\n/static/e6413c80a3d38d63b14543319d3c54dd/104b3/oauth2.png 960w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Indrasen Kumar","github":"indrasen715","bio":"A software engineer who continually seeks clean, elegant solutions to business challenges. My lifelong passion for technology drives me to proactively expand my horizons, constantly exploring and evaluating new languages, platforms, frameworks, tools, and best practices and applying them in my work to produce truly awesome results.","avatar":null}}}},"pageContext":{"id":"df511249-12dd-584f-8b40-3a1e682951ad","fields__slug":"/engineering/oauth2/","__params":{"fields__slug":"engineering"}}},"staticQueryHashes":["1171199041","1384082988","1711371485","1753898100","2100481360","229320306","23180105","528864852"]}