How OAuth works?

image credit: docs.microsoft.com

OAuth (Open Authorization) is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This is the Wikipedia definition for OAuth. As usual it is not exactly useful for newbies or people who are not aware about concepts of access delegation. Let’s try to break it down into the part which are easier to understand.

First of all, let’s understand about the terminologies used in the process of OAuth.

1. Resource Owner: Resource owner is the end user who wants to sign into the desired portal or website. If that website provides you an option to sign in using Facebook profile, then Facebook profile is the resource and you as end user are it’s owner.
2. Client App: Client application is the portal or website you want to sign into. They need some means to authorize you as an user, so they need your Facebook profile or Google profile.
3. Authorization Server: Authorization server is the server which client app needs to use to verify their identity using client credentials. The website you want to use will have their own profile on Facebook server with their own client ID and client secret. This server provides the client app an authorization code or token, which will be used to generate access token.
4. Resource Server: Resource server is the Facebook server which can actually access your profile. To call this server, client app will use the access token that was generated earlier.
5. Redirect URI: It is the URI provided by client app which is used by authorization server to return authorization code or token along with other details if necessary.
6. Scope: It is the scope of operations that client app can perform with the actual resource. For example if you agree to provide profile read access, then this scope will be used when client app generates authorization code as well as when it generates access token.

Now let’s jump into the process. This will give you a fair idea about what happens behind the scenes when you click on Sign In using Facebook or Google.

The flow gets initiated when an end user clicks on Sign in or Log in using Facebook, Google etc. By the end of the flow, the client application will have access to the user profile from given platform. The client app then calls authorization server with client ID, client secret, scope and redirect URI as primary parameters. Then after authorizing client app, authorization server raises as pop-up window asking consent from the end user. It might be something like “XYZ wants to view your profile pic, email address and location. Do you want to grant them permission to access these resources?” Once the user clicks “Allow” or “I Agree”, authorization server generates an authorization code or token and sends it back via redirect URI.

At this point, client app has the authorization code/token which it can use to get access token from authorization server. Client app calls authorization server for access token this time. If everything else is correct i.e. client ID, client secret, scope etc. the authorization server grants the access token to client app. This process of getting access token happens via backchannel as access token is highly confidential. Using this access token anyone can directly access the resources from resource server. As protection against malicious activities, communication regarding access token happens directly between client server and resource server.

Now the client server has the access token, it can be used to access the resources from resource server according to whatever scope that was configured earlier.