Skip to main content

Introduction to OAuth

What is OAuth?

OAuth is a protocol that allows distinct parties to share information and resources in a secure and reliable manner.



OAuth needs to consider the 2 concept to provide the informations in secure and reliable manner. They are authentication and authorization.
  1. Authentication -> Validating the person/system who need the information
  2. Authorization -> After authentication what action can be performed by the person/system.
By maintaining this 2 concept OAuth is providing federated identity and delegated identity.
  1. Federated identity -> User can use his/her one application account to login another application.
[Example: If a user having Facebook account then he can login Instagram with the same login as Facebook]
  1. Delegated identity -> One service can access another service resources.
[Example: When creating a Facebook account with eMail address that will suggest the contacts in the eMail to add as friends]

Without OAuth

With OAuth

  1. User gives the full rights for the 3rd party app to access anything with his/her account in another app.
  2. The app which gets the full rights can save the user’s critical/confidential information.
  3. The password of the user can be disclose to another 3rd party applications.
  4. User can not revoke the access.
  1. User is not giving the full rights to access his/her account.
  2. App can not store the credentials of the user.
  3. User can be safe if the 3rd party app disclosed/hacked
  4. User can revoke the access when he/she wants.

OAuth can be build in 4 steps

  1. Register your client application
  2. Get your access token [using client side flow/server side flow]
  3. Use your access token to access a protected resource
  4. If applicable refresh your access token [server side flow -access token expired use the refresh token to get new access token]

Register your client application

  1. Client ID -> Application unique identifier. [client name can be duplicated and name is for the human readings]
  2. Client Secret -> Secret key use by the application to identify itself when making requests.
  3. Redirection Endpoint -> The endpoint which is used by the service providers to send you response. [tokens/errors]
[This redirection endpoint will be provided by us most of the time when we are creating the application. But in some certain cases, such as installed desktop/mobile application redirection endpoint will be provided by the provider]
  1. Authorization endpoint -> An endpoint which uses by the client app to initiate the authorization flow. [this will be determined by the service provider]
  2. Token endpoint -> Endpoint use to initiate the token flow by the client application. [This will also determined by the service providers]

Get your access token

After the app registration we can fetch the access token. When accessing the access token our application can be considered as trusted and untrusted application. If our application is trusted, then our app could use authorization code grant flow. If our application is untrusted, then it could use implicit grant flow.

Access token has 2 properties known as scope and duration of access respectively.
  1. Scope -> what are the protected information can be accessed by the token holder. [This scope can cover a wide range of protected resources, such as the ability to read and modify any data with a particular user's account, or it can be as fine-grained as the ability to only fetch the first name of a given user]
  2. Duration of access -> Time limit of access to the protected information. [perpetual token - no time expiration]
  3. Token revocation -> In some certain cases we have need to terminate the access before it expires. [revoking the access]
  4. Refresh token -> Token which is refreshing the session by requesting a new access token when the current one expired.

Use your access token

After get the access token, then we can make API-Application program interface calls. [API differ according to their services, but the way passing the access token will remain same]

There are multiple ways to pass the token, they are authorization request header field, form encoded body parameter and URI query parameter. [Example: After getting the access token from the Facebook access token holder can make the call to Facebook Graph API to get the user’s protected information]


Refresh your access token

Most of the access tokens are having expiration periods. Once it expires, it can not use to access the user’s protected information. So, to continue to access protected resources there are 2 options.
  1. Do the authentication process again. [Start from the initial step]
  2. By using refresh access token to establish new session by getting new access token.

Overview of OAuth Steps

Comments

Post a Comment

Popular posts from this blog

Bandit Wargame – Documentation

Basically wargames are providing the basic knowledge on the security concepts. It is a game that contain many tricks to break the borders to gain the access especially passwords (commands are mostly on the Linux CLI). You can find many wargames through the Internet and they are very interest and fun full too. “Bandit” is also a wargame which is for the beginners. You all can access that through the link given bellow. And this article is an document for this game. I have used Ubuntu as the operating system. Bandit – Clickhere . Level 0: Case study → Clickhere Here we have need to connect the host through the SSH (secure socket shell) server. The informations are provided as follows. Host name: bandit.labs.overthewire.org Port No: 2220 User name: bandit0 Password: bandti0 There are many ways to connect through the SSH server. Method 1: Download and run the “PuTTY SSH client”. ( https://the.earth.li/~...
Post a Comment
Read more

How OIDC run on top of OAuth - Demo by a maven web application

As I said in the previous blog about OIDC, OIDC is running on top of OAuth in-order to provide authentication and authorization. When it comes to real scenario, we have need to clearly understand the flows between authorization server, and resource server. For OAuth it needs token introspection endpoint in-order to validate the token. But, in OIDC it doesn't need to have this introspection endpoint because OIDC response token (JWT) it contains the idtoken which contains information about the token to validate by the resource server. OIDC is running as authorization grant type is pretty much safe way for the web applications. Let's see how a real world application using this OIDC on top of OAuth. Note: I have created an sample application to provide the graphical interface for this explanation. When you are trying to login a online web application account you may see another login options also available. For example, login with Google, login with Facebook,etc. Those ...
Post a Comment
Read more