Identity, Security, and Software Beyond the Browser

Two questions

• Authentication: "Who are you?" Password, phone code, fingerprint, Google login
• Authorization: "What may you do?" May Dana see order 90? Sam's order 88? Issue a refund?
• Office building: the badge check is authentication; which doors open is authorization
• Authorization is organised by roles: customer, staff, manager, administrator

Never store the password

• Store a hash: a one-way scramble that cannot be reversed. Check a login by hashing what was typed
• A stolen database then reveals no passwords. (Salted, with slow algorithms such as bcrypt)
• If a company can email you your old password, it is doing this wrong
• Multi-factor authentication: something you know + something you have (or are). Require it for staff
• Passkeys: a device-held key unlocked by fingerprint or face; no password at all

Consequences

• The cookie is as good as the password while it lasts: HTTPS-only, invisible to JavaScript, re-ask for sensitive actions
• This is exactly what lets stateless, load-balanced servers work
• The same mechanism lets advertisers track browsers across sites: hence consent banners
• Apps and APIs often use a signed token (a JSON Web Token) sent in a header instead of a cookie

API keys are passwords for programs

• A long random secret a provider issues so it knows whom to bill
• Stored in server configuration (environment variables, a .env file); never in front-end code; never in Git
• Bots scan GitHub constantly for leaked keys and can spend thousands within minutes

The problem OAuth solves

• New apps want login without another password; apps want to use your Google Calendar or bank on your behalf
• Typing your Google password into a third-party app would give it everything, forever
• OAuth 2.0: the user approves a limited request at the trusted service; the app gets a valet key
• Four roles: resource owner (you), client (the app), authorization server (Google login), resource server (Google's API)

Why the roundabout design

• The password is typed only at Google; the app never sees it
• Scopes limit what the access token can do; the user sees them on the consent screen
• The one-time code is swapped for the token server-to-server, using the app's client secret
• Tokens expire in about an hour; the user can revoke any app with one click
• OpenID Connect adds an ID token for login; single sign-on lets employees use one company identity everywhere

Six ideas that catch most mistakes

• Encrypt in transit (HTTPS) and at rest (encrypted disks)
• Never trust the front end: prices, permissions, secrets live on the server
• SQL injection: user text pasted into a query. Typing ' OR 1=1 -- logs in as everyone. Frameworks prevent it with parameterised queries
• Least privilege: every person, program, and key gets the minimum access
• Secrets out of code and out of Git; rotate anything exposed
• Patch software and test that backups restore

Where the front end runs

What this explains

• "We need an app" is a new front end if the API exists, and secretly a back-end project if it does not
• Companies start with the web: no store review, no commission, one codebase, instant updates
• The API outlives several generations of front ends
• Embedded devices are the exception: a 2026 thermostat must work in 2036; a mistake is a recall, not a redeploy

Three practical consequences

• The API key stays on the server: a call from the browser exposes it to every visitor
• Your data is the differentiator: add this customer's history and your catalogue to the prompt (RAG)
• AI calls cost money per token, take seconds, and can fail: cache, monitor, and give them a fallback