OAuth 2 Authorization Framework
Before OAuth
You would have to provide your username and password to third-party.
Problems
- Apps store the user's passwords
- Apps get complete access to user's account
- Users cant revoke access to the app except by changing password
- Compromised apps expose user's password
Before OAuth 1
- Password authentication was used
- Many services implemented things similiar to OAuth 1
- Each implementation was different
Then comes OAuth 1
- OAuth 1 standardized how different services implemented authorization
- But there were some limitations
OAuth 2 Introduction
- Open standard to authorization
- Specifies how resource owners authorizes third-party access to their server resources
Terminologies
-
Resource Owner: The User
-
Resource Server: The API
-
Client: The third party application
-
Authorization Server: The server authorizing the client app to access the resources of the resource owner
Token Endpoint
Path on authorization server which is used by the client to obtain an access token.
Authorization grant
A well defined set of steps to obtain access token from an authorization server
- Authorisation code grant
- Implicit grant
- Password Grant
- Client credentials grant
- Refresh token grant
Authorisation code grant
Useful in traditional web apps
Step 1: Authorization Code Link
https://oauth2server.com/oauth?response_type=code&client_id=CLIENT_ID
&redirect_uri=REDIRECT_URI&scope=photos
Step 2: User Authorizes Application
Step 3: Application Receives Authorization Code
https://my-app.com/callback?code=AUTHORIZATION_CODE
Step 4: Application Requests Access Token
https://oauth2server.com/oauth/token?client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&grant_type=authorization_code&
code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
Step 5: Application Receives Access Token
{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 2592000,
"refresh_token": "REFRESH_TOKEN"
}
Implicit grant
Useful in browser-based and mobile apps
Step 1: Authorization Link
https://oauth.example.com/authorize?response_type=token
&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
Step 2: User Authorizes Application
Step 3: User-agent Receives Access Token with Redirect URI
https://my-app.com.com/callback#token=ACCESS_TOKEN
Password grant
Useful for your website or your mobile app
- Client sends username and password
- Authorization Server sends access token back
Step 1: Client sends request to Authorization server
https://oauth.example.com/token?grant_type=password&
username=USERNAME&password=PASSWORD&client_id=CLIENT_ID
Step 2: Client Receives Access Token
{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 2592000,
"refresh_token": "REFRESH_TOKEN"
}
Client credentials grant
Useful if applications can access resources on their own
- Client sends client id and client secret
- Authorization Server sends access token back
Step 1: Client sends request to Authorization server
https://oauth.example.com/token?grant_type=client_credentials
&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
Step 2: Client Receives Access Token
{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 2592000,
"refresh_token": "REFRESH_TOKEN"
}
Refresh token grant
- Client sends refresh token
- Authorization Server sends access token back
Step 1: Client sends request to Authorization server
https://oauth.example.com/token?grant_type=refresh_token
&refresh_token=REFRESH_TOKEN
Step 2: Client Receives Access Token
{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 2592000
}
Why Refresh Tokens?
- Because access token are short lived
- It is not viable to execute other grants every time access token expires
Custom grants
You can create your own custom grants for your own needs.
Step 1: Implement your custom grant
Using your favourite language or platform, implement custom grant on the authorization server
Step 2: Consume the custom grant
https://oauth.example.com/token?grant_type=CUSTOM_GRANT
&scope=read&key1=value1&key2=value2
Accessing resources
So you have an access token. Now what?
curl -H "Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia" \
https://api.example.com/me
Security Recommendations
- Always use https
- Issue short lived bearer tokens
- Don't pass bearer token in page URLs
Scope
Limiting access to resources
https://oauth.example.com/token?grant_type=GRANT_TYPE&scope=SCOPES
Scopes in authorization grant and implicit grant
Scopes are listed in the page where the resources owner authorizes the client
Implementing on OAuth 2 Server
- Read the spec very carefully
- Find a server library already written. A short list is available on http://oauth.net/2/