Reference video: https://www.youtube.com/watch?v=5th6CSQTdpM
OAuth is about "authorization" and not "authentication".
- Authentication is the process of verification that an individual, entity or website is who it claims to be.
- Authorization is the function of specifying access rights to resources.
If there was only authentication, then we know who you are (and that you really are you and not someone pretending to be you), but we don't know what you're allowed to access. e.g. a person enters an office building, but they might not be allowed to enter the IT computer room (without authorization the person can just walk into the IT computer room).
If there was only authorization, then we know what you can access, but we don't know if it's really you accessing the resource. e.g. a bad person stole an employee's key to get into the office's IT computer room but there was no security guard at the office's front door to check if the bad person was really the employee (i.e. really the owner of the key).
If you have a jacket, then the jacket is the "resource" and you are the owner of that jacket (i.e. you are the "resource owner").
If you put your jacket into a locker, then the locker is the "resource server".
The locker is locked. The lock is the "authorization server" (the auth server ensures only you can access your jacket).
If you ask your friend to get your coat for you, then you're asking them to act on your behalf and so your friend is a "client" or "application".
An access token is something you present to the resource server to get access to your resource that is stored there.
There are different ways to 'implement' an access token, such as a "Bearer Token", "JWT Token", "Opaque Token".
Access tokens are typically short-lived and once expired you need to get a new access token to replace the expired one.
A refresh token is a way to get more access tokens once they have expired.
A scope is equivalent to a "role" or a "permission". It indicates what can be accessed using the access token.
There are different ways for a resource owner to acquire an access token (in order of how common they are):
- Client Credentials: Service-to-Service communication (simplest).
- Authorization Code: Browser-based user login such as web, mobile, SPAs and CLIs (add PKCE for extra security, e.g. a public CLI code base which can't store secret data).
- Device Code: Televisions and environments with limited input capabilities
- Refresh: Obtain new tokens when one expires (works in tandem with the "Authorization Code" flow to help avoid having to do that full flow again when your token expires).
- Password & Implicit: Less secure option for CLI, mobile apps and SPAs (AVOID!).
Client is trusted and contains an id and a secret which are used to acquire the token.
This is analogous to you losing your key for accessing your resource in the resource server and so a janitor (the client/app) uses its trusted id/secret to open the lock (the Authorization Server) to retrieve your jacket (the resource).
This is very similar to Client Credentials, but highlights how insecure it is compared. Instead of having a client/app that is trusted you are giving your key to the lock directly to the client/app and they're opening the lock for you. Your key should only be held by you but now you've given it away to someone else temporarily who might accidentally lose the key or hold onto it and do bad things with it in the future.
This flow is "browser based" (making heavy use of HTTP redirects) making it a bit awkward for some devices like CLIs.
Most cases the user will be presented with a screen where they have to approve permissions being granted to the client/application.
It can be extended through the use of PKCE which means the client/application will generate a secret that is exchanged for an access token (still with permission approval screen).
This is analogous to you wanting to lend your jacket to your friend. Your friend goes to the locker and the lock (which is a very technically advanced lock) calls you to confirm it's OK for your friend to get access to your jacket. You enter your key (login) and confirm the access. Your friend is given a temporary key (auth code) and uses that to obtain a key (access token) to open the lock and gets the jacket.
NOTE: The "Implicit" flow is very similar to the Authorization Code flow but there is no "auth code" given out, the client/app is just given the access token immediately. So "Implicit" is less secure because of this as the access token provided to the client/application could get intercepted along the way (unlike with the "auth code" addition in the Authorization Code flow).
OpenID Connect is about "identity" (who you are, not what you can do).
It's an extension of OAuth2, so most of what we've already seen is the same with OIDC.
OIDC has an Authorization Code flow like OAuth2 which doesn't provide an "access token" (like OAuth2) but an "ID token" which is used to login to something (typically used with SSO).
There is also a "Hybrid" flow which gives you both an ID token and an Access token.
This is analogous to you wanting to go to a swimming pool, but it's members only. Someone at the gate redirects you to the ticket booth (authorization server) and once you show your ID (i.e. login) you are given back a wrist band (i.e. an ID token) which can be used to enter the swimming pool.