Authorization code: a value returned in the authorization code flow that is exchanged by the client for an access token. The authorization code cannot be used for anything else.
Authorization server: presents the UI for the user to approve the access request. May be the same as the resource server.
Access token: a token used on subsequent requests to give access to data.
Client: the application attempting to get access to the user’s account
Client ID: an identifier for the client. Public information.
Client secret: a private bit of information to confirm the client’s identity. Can only be kept secret for server-rendered applications.
Code challenge: the base-64 encoded version of the hash of the code verifier.
Code verifier: the original random string generated in the PKCE flow.
PKCE: “Proof Key for Code Exchange”. First used to secure native apps, now recommended for frontend JS and server apps as well, for additional security.
Redirect URI: a valid URL for the user to be redirected back to after the authorization code grant flow
Refresh token: allows retrieving new access tokens without presenting a UI to the user
Resource server: the API
Resource owner: the user
Scope: indicates which groups of the user’s data the client is requesting access for
State: a string sent by the client used to verify the response
Grant Types
Client Credentials
Used for machine-to-machine authentication
Providing username and password directly to API
One-legged: responds with access token directly
Resource Owner Password Credentials Grant (Password Grant)
Client ID, client secret, user’s login and password
One-legged
Best used for trusted clients; would not be used for a third-party app (because it allows the third party to snoop on the user’s credentials)
Example: signing into a third party site via central Auth service like Facebook, Google, Twitter, GitHub
Central service gets redirect URL
User sent to central service, log in, redirected back to third party app with an authorization code
Auth code sent with client ID and secret to get access token
Why? Because a man in the middle attack can intercept this authorization token, but this way they can’t use it unless they also have the secret from the server.
Three-legged
PKCE
Client makes up and stores a one-time secret: the code verifier
Client hashes the code verifier: the code challenge
Client tells the server the code challenge and algorithm
Server stores the code challenge and algorithm for the auth code it generates
On auth code redemption, client tells the server the unhashed code verifier
Server hashes the code verifier and ensures the hash matches the code challenge it previously sent
Implicit Grant
Do not use; security issues: access token available in URL to client, instead of only seen on server
Access token directly
Used by clients where you can’t protect your secret, like a frontend webapp
Security Features
Only issue short-lived access tokens, like an hour
Refresh tokens that are longer-lived (Alex suggested indefinitely)
Have to resend the secret
Does that mean doesn’t provide security benefit for client-side apps? Alex says correct
Sometimes no refresh tokens used, access tokens live indefinitely
Questions
Why do you need a server?
To store a secret, so you can use the authorization code grant
Why? Because without a secret you’re vulnerable to a MitM attack, but with a secret you aren’t.
Why? (TBD)
Would it be worth it to create a server just to store the secret, even if there is no other server functionality? (TBD, test this)
Why return cookie to user, instead of access token (from third party service)?
Server-rendered app can use CSRF, SPA can’t easily