Delegated access.
WHAT PROBLEM IT SOLVES
Letting an application act on a user's behalf without holding their password.
WHAT THE PARTIES ARE
The user The application The authorisation server The service holding the data
WHAT THE FLOW BROADLY IS
The application sends the user to the authorisation server The user approves The application receives a code The application exchanges the code for a token
WHY THE CODE STEP EXISTS
So the token never passes through the browser.
WHAT SCOPES ARE
Limits on what the token permits.
WHAT TO REQUEST
The minimum needed.
WHY
Users refuse broad requests, and a stolen token does less.
WHAT AN ACCESS TOKEN IS
Short-lived, used on each request.
WHAT A REFRESH TOKEN IS
Longer-lived, used to obtain new access tokens.
WHY THAT SPLIT
It limits the damage of a stolen access token.
WHAT TO STORE SECURELY
Refresh tokens, which are effectively long-term credentials.
WHAT TO HANDLE
Tokens expiring mid-operation Refresh tokens being revoked The user withdrawing permission
WHAT TO DO WHEN REFRESH FAILS
Prompt the user to reconnect, rather than failing silently.
WHAT TO NEVER DO
Use the flow intended for browsers in a server application, or the reverse.
WHY
Each has assumptions the other breaks.