OAuth — The Next Step in Access Delegation?
What comes onto your mind when you hear the word OAuth? Well, if it is authorization and authentication, you are partially correct. OAuth or Open Authorization is an access delegation (i.e. granting someone else access, in this case a third-party web application, mobile application, etc. on behalf of you to use something that belongs to you) protocol which is made to be used on HTTP protocols. This authorizes a certain third-party application to access a resource owned by you, which is stored in a resource server. I’ll explain the specifics later in this post. Basically, what this does is that it allows the account details of a user (say for example from Google or Facebook) to be shared with the third-party application without actually sharing the login credentials with anyone. Neat, right?
Now that you have a general idea of What OAuth is, I’ll do one better. Why OAuth? The main reason for the introduction of OAuth was to avoid sharing user’s login credentials with anyone else. Before the introduction of any of those protocols, users had to share their login credentials with the third-party applications to give access. This meant giving the password in plain text which completely negated the purpose of a password. This raised lot of problems because the apps could use those credentials to access the resource without users’ knowledge, and user had no control over the allowed access duration or the features/scope to which the app can access.
All these are handled by OAuth by providing a different set of credentials to the third-party application through tokens. Knowingly or unknowingly, you may have used this protocol in numerous occasions.
For example, if you use Google to login to your Medium account, you’ll see something like above in the browser. If you look closer, you’ll be able to see the word “oauth” in it. This implies that you are using OAuth protocol to delegate access to Medium.
Once you login to your Google account, you will be redirected to this page where you have to authorize the particular app. This is a general scenario where you’ll use OAuth protocol to allow the third-party app(Medium) to access your profile data such as name, email, and profile picture through Google.
How does it work?
Before looking in to the procedure, you have to understand the four main roles involved in the process. Those are,
- Resource Owner — Entity capable of granting access to the protected resource. If the resource owner is a person, then it is usually known as the end-user.
- Client — An application making requests from the protected resource on behalf of the resource owner and with its authorization. This could be a web application, mobile application, native application, etc.
- Authorization Server — The server responsible for issuing the tokens once the resource owner authentication is successful and authorization is granted.
- Resource Server — Server hosting the protected resource.
The previous OAuth version, 1.0, is now obsolete. So. I’ll be focusing in OAuth 2.0 in this post. There are several flows involved with OAuth 2.0. Namely, Authorization Code Grant, Implicit Grant, Client Credentials, and Resource Owner Credentials. Authorization Code Grant, the most widely used flow would be the best way to understand the OAuth 2.0 protocol. Authorization Code Grant has two main steps in the process.
Obtaining Authorization Code
Whenever a client wants access to a certain resource, it sends a GET request to the authorization server with several parameters such as response type (Usually “code” for this flow. This allows the server to understand what type of response is expected by the client), scope of the request, client identification (This is an identification code client receives when it registers with the authentication server), redirect URI and state. Once this reaches the authorization server, server asks the resource owner to authorize the request and if it is authorized, the client is given an authorization code. This is a one-time use credential containing the user’s authorization decision.
Once the above step is done, the client sends a POST request to the authorization server with the authorization code, grant type, redirect URI, client identifier and client secret in case of a confidential client (an application implemented on a secure server with restricted access). Server takes this request and checks whether it is valid, and if so, sends back a JSON object containing the access token, id token (If OpenID Connect was involved), token type, expiration time, and refresh token (optional). The client can use this access token to access the protected resource within the given scope while the expiration time is not exceeded.
I guess you now have a general idea as to what OAuth is and how it functions, which you have been using for so long without actually knowing what it is. So, I’ll leave it up to you to decide the answer. Is this the next step in access delegation?