Understanding
auth
Every system needs to know who is asking and what they are allowed to do. Four methods cover most of what you will meet: passwords, keys, magic links, and OAuth.
Scroll, click, or use the arrow keys to move through.Scroll, or use the arrows and dots to move through.
Authentication is who you are. Authorization is what you may do.
Every login and every connection answers both questions. First the system establishes an identity, then it checks that identity against a set of permissions before doing anything. The four methods in this lesson are different ways of answering the first question; the second is always a lookup against what that identity has been granted.
Something you know.
The classic. You prove who you are with a secret only you should know, and the system compares it against a scrambled copy it keeps. Simple and universal, and also the method with the most famous failure modes: people reuse passwords across systems and get tricked into typing them into fake pages. That is why password managers and second factors exist.
A password for programs.
A long random string the system issues once, and the calling program sends with every request. The key identifies which program is asking and what it is allowed to do, and it can be revoked or rotated without touching anything else. The rule that matters: a key is a secret. Keep it out of shared documents, out of code that gets published, and out of anything a model reads. Don’t give them to your AI.
Prove you own the inbox.
The system emails you a one-time sign-in link, and clicking it is the whole login. The credential is possession of your email account, so there is no password to remember, reuse, or steal from the system later. The trade: your email account becomes the front door, so everything now depends on how well that account is protected. There are systems that use text message in the same way.
Approved at the source.
The flow behind “Sign in with Google” and every connect-your-account button. You approve the request at the provider you already trust, and the application receives a token that carries exactly the permissions you approved, nothing more. The application never sees your password, and you can revoke the token at any time without changing anything else.
Four ways to answer the same question: who is asking?
A second proof, added on top.
Two-factor authentication is not a fifth method. It is an extra security step layered onto any of the others: a code, an app prompt, or a hardware key that proves you also hold something physical. Passwords with 2FA is the common pairing, magic-link systems can require it, and OAuth carries the provider’s 2FA with it. For API keys, it protects the account that issues the key. The forms are not equal: text-message codes are better than nothing, authenticator apps are better, and hardware keys are the strongest. Turn it on everywhere that matters, and start with email, because email is the recovery path for everything else.
Three rules cover most of it.
Secrets stay secret
Keys and passwords never go in shared documents, published code, or chat messages. Once a secret has been seen, treat it as leaked and rotate it.
Least privilege
Grant the narrowest access that does the job: read-only where read-only works, one system rather than all of them, this month rather than forever.
Revocable beats permanent
Prefer credentials you can cancel: scoped tokens, per-app keys, per-person logins. When something goes wrong, you turn off one key, not the whole system.
Decide what each identity may do.
Roles, not one-offs
Grant permissions through roles like admin, editor, and viewer, rather than person by person. Access stays consistent, and reviewing it means reading a short list instead of an archaeology dig.
Review and expire
Access accumulates. Audit who has what on a schedule, remove what is unused, and end access when a role changes or a person leaves, the same day.
Guard the dangerous actions
Reading is not writing, and writing is not deleting. Put the destructive and financial actions behind a higher tier, an extra confirmation, or a second person.
The model does the work. It should never hold the keys.
An AI agent acting on your behalf needs access, and how you grant it matters. Give the agent a scoped key or an approved token, never your password. Let the surrounding system hold the credentials and make the calls, so the model uses the access without ever seeing the secret. A well-set-up tool makes this the default; it is worth checking that yours does.
Access for the agent, secrets in the system.
Identity first, permission second, and the secrets stay out of sight.
Passwords for people, keys for programs, magic links for password-free sign-in, OAuth for connecting systems. Scope everything tightly, keep every credential revocable, and never let the model see a secret.