Security Scenarios
Listed below are different security scenarios with notes. The order is less security features to more. The intent is to keep the text light and the summaries high level. It's up to you and your needs to decide how much or how little security to implement.
Since major parts of OAuth2 are built on Basic Authentication, I list it as a "zero implementation" point where you decide to not implement OAuth2 at all.
The basics of when a user authenticates using Basic Authentication
Step 1, Send Basic auth user id and password with API call
GET product/API/endpoint HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Step 2, Receive data on successful authentication
{ json data returned }
The basics of the user authenticating with multiple devices
Each device must store the user's id and password in memory for the duration of the session because each API call requires the user's id and password to be sent. If a device wants to remember the user for a longer period of time, such as weeks at a time, that device will have to store the user's id and password securely on the device.
PROS:
- Simple
- Not many moving parts
- It works
CONS:
- You have to store the user's id and password in memory to make API calls
- You have to send the user's id and password each time you make an API call
- Each device is responsible for securely storing the user's id and password if using persistent sessions
- The device's persistence session is limited to the user's password policy
- Cannot identify and track which device type is making authentication calls
- If a device is lost or compromised, the user has to reset their password. In the interim, an attacker has full access to all systems in which that user's id and password are valid
- No large well known technology company uses this approach
- Not many medium to small sized technology companies utilize this approach
This is for when a client requests an access token using only its client credentials. A client is defined as a software program and client credentials is defined as a software program's own password that is separate from a user's password. Sometimes the client's password is also referred to as its "client secret".
You can misuse this grant type to send user id and passwords in exchange for access tokens. Typically, you would use the Resource Owner Password Credentials below as it was designed specifically for that purpose. I'm showing this misuse as it's possible to do and slightly simpler than the Resource Owner Password Credentials.
The basics of when a user authenticates using Client Credentials
A sample API call would look like
Step 1, Send basic auth user id and password
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
Step 2, Receive access token
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":3600,
}
Step 3, Send access token with API call.
GET product/API/endpoint HTTP/1.1
Host: server.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Step 4, Receive data on successful authentication
{ json data returned }
The basics of the user authenticating with multiple devices using Client Credentials
Each device must store the user's access token in memory for the duration of the session because each API call requires the user's access token to be sent. Each device has a different and unique access token. Each user's access token can be individually revoked per device. If a device wants to remember the user for a longer period of time, such as weeks at a time, that device will have to store the user's access token securely on the device.
PROS:
- Not difficult to understand
- The user's password is only sent over the network for an initial handshake
- The user's password never has to be stored on any device, including memory of the device
- Access tokens are unique between devices
- If a device is lost or compromised, the access token has to be revoked. However, the user does not have to reset their password. In the interim, an attacker only has access to data that particular device has access to. The attacker cannot use the access token on any other device
- Access tokens can have variable life spans independent of a user's password policy
- Large and well known technology companies will use this approach (just not as a misuse as outlined here)
- Many medium to small sized technology companies utilize this approach
CONS:
- More moving parts
- Cannot identify and track which device type is making authentication calls
- Cannot block a particular device type from making authentication calls
- It's a technical misuse to authenticate users this way
This grant type is suitable for getting an access token from a user's id and password using a client id (software program's id) and a client secret (software program's password). The only difference between this and the client credentials above is that you must send the software program's id and password along with the user's id and password. Doing this gives a larger range of security features.
The basics of when a user authenticates using Resource Owner Password Credentials
A sample API call would look like
Step 1, Send basic auth user id and password
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
Step 2, Receive access token
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":3600,
}
Step 3, Send access token with API call.
GET product/API/endpoint HTTP/1.1
Host: server.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
Step 4, Receive data on successful authentication
{ json data returned }
Resource Owner Password Credentials involving multiple devices authenticating
Each device type's software should have a unique client id and password/secret. In the above example, there would be a total or three. One for Phone, PC, and Tablet. Each device must store the user's access token in memory for the duration of the session because each API call requires the user's access token to be sent. Each device has a different and unique access token. Each user's access token can be individually revoked per device. If a device wants to remember the user for a longer period of time, such as weeks at a time, that device will have to store the user's access token securely on the device. Each device type can be individually revoked.
PROS:
- If the same client id/secret is used across all device types this operates identical to the Client Credentials
- The user's password is only sent over the network for an initial handshake
- The user's password never has to be stored on any device, including memory of the device
- Access tokens are unique between devices
- If a device is lost or compromised, the access token has to be revoked. However, the user does not have to reset their password. In the interim, an attacker only has access to data that that particular device has access to. The attacker cannot use the access token on any other device
- Access tokens can have variable life spans independent of a user's password policy
- You can block a particular device type from making authentication calls
- Optionally, if implemented more thoroughly, individual devices can be blocked
- Can identify and track which device is making authentication calls
- Optionally, if implemented more thoroughly, individual devices authenticating can be tracked
- Large and well known technology companies use this approach frequently
- Many medium to small sized technology companies utilize this approach
CONS:
- The client id and secret add more complexity and moving parts
- The client id and secret per device type has to be generated