Understanding OAuth 2.0: A Beginner’s guide in simple steps
Let’s understand before OAuth:
You would have to provide your username and password to the third-party systems, which compromises security aspects like :
- Credential Exposure.
- Apps get complete access to user’s account.
- Users cannot revoke access to the app except changing password.
- No guarantee that the organization will keep your credentials safe.
Introduction to OAuth 2.0
- OAuth 2.0 is an open standard to authorization.
- It is a security standard where you give one application permission to access your data in another application.
- The steps to grant permission , or consent is referred as delegated authorization.
- You authorize one application to access your data, or use features in another application on your behalf without giving them your password.
OAuth 2.0 Illustration with Example
Let’s say you have discovered a website/app named “Motivational Quote of the Day” which sends a motivational quote as text message every day to your phone.
You love it so much, you want to share this site with everyone you’ve have met online. However writing an email to every person in your contact lists sounds like a lot of work.
Good thing, “Motivational Quote of the Day” has a feature to invite your friends.
The example above, along with numerous others we may have come across in our day-to-day activities, is known as an OAuth Flow.
The OAuth flow in this example is made visible of steps of grant consent, and some invisible steps of secure way of exchanging information.
This example uses the most common OAuth 2.0 flow, known as “authorization code” flow.
OAuth 2.0 Terminology :
Resource Owner : You! You are the owner of your identity, data and any actions that can be performed with your user accounts.
Client: The application that wants to access data or perform actions on behalf of the Resource Owner (It’s motivational quote application from above example).
Authorization Server: The application that knows the Resource Owner where the resource owner already has an user account.(It’s mail server account from the above example).
Resource Server : The server hosting the protected resources like the Application Programming Interface (API) or service the Client wants to use on behalf of the Resource Owner.(It’s contacts API from the above example)
Redirect URI : The URL the Authorization Server will redirect the Resource Owner back to after granting permission to the Client. This is sometimes referred to as the “Callback URL.”
Response Type : The type of information the Client expects to receive. The most common Response Type is code, where the Client expects an Authorization Code.
Scope: These are the granular permissions the Client wants, such as access to data.
Consent: The Authorization Server takes the Scopes the Client is requesting, and verifies with the Resource Owner whether or not they want to give the Client permission.
OAuth 2.0 Flow step by step explanation from the above Illustration:
Step 1 : You, the Resource Owner, want to allow “Quote of the day,” the Client, to access your contacts so they can send invitations to all your friends.
Step 2: The Client redirects your browser to the Authorization Server and includes with the request the Client ID, Redirect URI, Response Type, and one or more scopes it needs.
Step 3: The Authorization Server verifies who you are, and if necessary prompts for a login.
Step 4: The Authorization Server presents you with a consent form based on the scopes requested by the client. You grant (or deny) permission.
Step 5: The Authorization Server redirects back to client using the redirect URI along with an authorization code.
Step 6: The Client contacts the Authorization Server directly (does not use the Resource Owner’s browser) and securely sends its Client ID, Client Secret, and the Authorization Code.
Step 7: The Authorization Server verifies the data and responds with an access token.
Step 8: The Client can now use the access token to send requests to the Resource Server for your contacts.
What does the terms Client ID, Client Secret, and Authorization Code mean?
These are the key components that help in the secure exchange of authorization and access tokens between a client (application : “quote of the day application in the above example”) and the authorization server.
Client ID : A public identifier for the client application which is used for informing the authorization server about which client is making the request.
Client Secret : A confidential string which is known only to the authorization server and the client(application). This is used to authenticate the client to the authorization server and ensure that the request is coming from a legitimate source.
Authorization Code: A temporary code that the client will exchange for an access token. It is obtained after the user successfully authenticates and authorizes the client application.
Requesting OAuth 2.0 Token via Postman:
Select the authorization type as OAuth 2.0 from the dropdown and configure the token details as below:
Token Name: The name you want to use for the token.
Grant Type: A dropdown list of options. This will depend on the API service provider requirements. In the above illustration we are using the authorization code as the grant type. For different grant types refer to https://oauth.net/2/grant-types/
Callback URL : The client application callback URL to redirect to after auth.
Auth URL: The endpoint for the API provider authorization server, to retrieve the auth code.
Access Token URL: The provider’s authentication server, to exchange an authorization code for an access token.
Client ID : The ID for your client application registered with the API provider.
Client Secret: The client secret given to you by the API provider.
Scope: The scope of access you are requesting, which may include multiple space-separated values.
Hope this gives you a basic understanding on using OAuth 2.0. Thanks for taking time to read.