Authentication process of verifying an identity. We confirm they’re who they say they are. (username & pwd).
Authorization process of verifying what someone is allowed to do. (Permissions and access control).
Past solutions
From worst one to best one and the problems they originate:
Credential Sharing
The worst one. An App is not able to differentiate between real user access and programmatical access.
Permissions are typically too broad. It also the ability to access more content than it should.
Cookie
We could redirect the user off to the API where they could enter their credentials and get a cookie. This allows an app to access the API.
Dangerous because CSRF attacks. We’ve authorised the whole browser and not the app.
API Keys
We ask an user to enter a key that was given to them by the API. They solve a lot of problems, but still struggle with apps that cannot keep a secret.
They have their own set of issues.
OAuth 2.0
OAuth 2.0 is an authorization framework specifically built for APIs. It allows an user to delegate API access to an app. They define what it’s allowed to use. Then the App can talk freely to the API on the user’s behalf.
It’s a delegation protocol.
We have 4 resources:
- Protected Resource (HTTP API)
- Client App (requesting application)
- Resource Owner (user)
- Authorization server
User authentication can be done through Google or any other methods. They then need to consent to OAuth.
When the protected resource receives an access token it has to verify it in some way. This depends on the exact structure (such as JWT [Json Web Token]).
We could verify it within the protected resource or send it to the authorization server to be validated.