Hasty Briefsbeta

An Illustrated Guide to OAuth

16 days ago
  • #Authentication
  • #OAuth
  • #Security
  • OAuth was introduced in 2007 by Twitter to allow third-party apps to post tweets on users' behalf without sharing passwords.
  • OAuth uses access tokens, which act like API keys specific to a user, allowing apps to take actions or access data on the user's behalf.
  • The OAuth flow involves user consent (resource owner granting permissions) and the authorization code flow (app exchanging an authorization code for an access token).
  • Security in OAuth is maintained by avoiding sending access tokens in URLs and instead using authorization codes exchanged via secure backend requests.
  • OAuth terminology includes resource owner (user), OAuth client (app), authorization server (where users log in), and scopes (permissions granted).
  • Registering an OAuth app requires providing an app name and redirect URI, with the service issuing a client ID and client secret.
  • The OAuth process involves redirecting users to the authorization server, where they log in and consent to scopes, then returning an authorization code to the app.
  • Front-channel (insecure, visible in URLs) and back-channel (secure, encrypted POST requests) are key concepts in OAuth flows.
  • PKCE (pronounced 'pixie') is a method for securing OAuth flows in apps without a backend, such as mobile or JavaScript apps.
  • OAuth can vary in implementation, including implicit flows (less secure) and refresh flows for expired tokens, with OpenID Connect (OIDC) adding login functionality.