User vs Service
There are 2 type of "thing" we can authenticate. When we talk about authentication, we're talking about how we can identify something and make sure they are who they say they are.
It's a bit like being asked at the airport for your passport. You're asking for access to another country, the security guards are asking you to identify yourself, so you provide them with your passport which acts like a username and password. If successful, they give you access to the country.
On the internet, we generally want to authenticate whether access is being given to a user or a service.
A user is probably what you're most familiar with. It's typically a login screen where you enter a username and password. This is where we need a person to manually complete a form telling us they are who they say they are.
The other type of authentication we do, is service authentication. A service is usually an API or server. An example of when this might be useful is during a CRON job. Cron jobs run automatically at certain times of the day, week, month or year. When the CRON job runs, it might need to make an API request to another server to get data it needs. In order to call the API the service making the call needs to authenticate itself so the API knows it's a valid request coming from ITC.
In this scenario, we don't have a user that can fill out a form, so we need a way to provide programmatic access.
OAuth provides 2 different grant types to authenticate whether access is being requested from a user or a service.
Client Credential tokens should never be used by a user, or stored in a users session. Client credential access tokens generally have a much long expiry time compared to a user, and usually have far greater access to resources.
For example, a client_credentials access token might be valid for a year before it expires, whereas a user based password token might only be valid for a day.
This is because it's highly unlikely that a client_credential access token will become compromised because it's only used internally between services, so we can trust it more. Users might accidentally leave themselves logged into a platform, so we need to automatically expire these tokens quicker so that if an attacker does manage to get hold of a valid user access token, they only have a very limited amount of time before it expires.
- Name
Password Grant- Required
- Type
- password
- Description
Password grants are used when we want to authenticate a user. This will require a username and password to be provided as well as client ID and client Secret of the application requesting authentication
- Name
Client Credentials Grant- Required
- Type
- client_credentials
- Description
Client Credential grants are used when we want to authenticate a service programmatically. In these requests, it only requires a client ID and client secret.