---
# System prepended metadata

title: OAuth 2.0

---

# OAuth 2.0

### We need to answer the following questions...


**What is OAuth?**
 - OAuth is an authorization protocol.
 - Authorizes a thirdparty app on behalf of a user. In other words, it delegates access to a thirdparty app based on the permission of the user.
 - It prevents the need to give away sensitive user credentials such as passwords to other apps in order to give them access to a service that holds the user's resources.
 - In a typical Oauth flow, a number of actors are involved:
 
     - user
     - client (the third party app)
     - oauth server (authorization server)
     - resource server 


The following are also part of the Oauth flow

- clientId
- clientSecret
    - clientId and clientSecret are normally created at a portal provided by the authorization provider. They need to be part of the request that is made to the authorization server when the user wants to delegate access to a thirdparty client.
- redirect uri
    - The redirecturi is sent to the authorization server together with the clientid and clientSecret. Upon validating the client creds, the server redirects the user to this URI.
- scopes
- grants
- authorization code
    - The authorization server sends a code as a query param in the redirecturi. The code needs to be parsed and get sent back to the authorization server to obtain an access_token.
- access_token    
- refresh_token
    - The access_token and refresh_token are sent to the thirdparty app (client) from the authorization server. The access_token will normally have an expiry. The refresh_token normally lasts longer than the access_token. The purpose of the refresh_token is to have a new access_token from the auth server when the existing access_token expires. This will help the user from from having to send their credentials to get authenticated again.  
    - Now, the client has the access_token, it will make the access_token part of the request to the resource server.
    - The resource server, upon receiving a request from the client, parses the access_token, sends it to the authorization server to get confirmation that it is a valid token. If the auth server verifies the token as valid, the resource server allows the request from the client to go through.



**What are the alternatives (saml etc...)?**

**Pros and Cons in relation to the alternatives?**

**What are the steps of authorization? **
Give examples that are relatable... (we will use illustrations and diagrams here).

- authorization
- client app
- authorization server
- resource server
- scopes
- access token
- callback
- etc...

**An example of Oauth...**

Lets say you have a social media app that has a number of users. Lets call this app, MyApp. Some of your users are also avid user of Twitter. They post tweets regularly. MyApp could let the users automatically post whatever they tweet on twitter.