How software works · Guide for product managers

Authentication and authorization for product managers

Sign-in is the first thing every user touches and one of the easiest places to ship a serious bug. This guide separates the two ideas engineers keep saying together — authentication and authorization — and explains the building blocks well enough for you to write good requirements and review what an AI agent builds.

Guide 4 of 10 in the technical PM path

11 min read · Updated 25 September 2026 · By the TechPMer team

Why a PM should care

Auth decisions show up everywhere in the product:

• Conversion. Every extra step at sign-up loses people. Social login, magic links and passkeys change that funnel.
• Enterprise deals. Larger customers often require SSO, roles and audit logs before they sign.
• Security incidents. Most data leaks in small products are not hackers breaking encryption — they are missing permission checks.
• Support load. "I can't log in" and "I lost access" are some of the most common tickets.

Authentication vs authorization

The two words sound alike and mean different things:

• Authentication (AuthN) answers "Who are you?" — proving identity with a password, a code, a Google account or a passkey.
• Authorization (AuthZ) answers "What are you allowed to do?" — can this person view this project, edit this invoice, invite users?

An analogy: at an office building, showing your badge at the entrance is authentication. Whether your badge opens the server room is authorization. Many bugs come from checking the first and forgetting the second.

Ways users sign in

Most products combine two or three of these. Building your own password system from scratch is rarely a good idea; teams usually rely on an auth provider or a well-tested library.

Sessions, cookies and tokens

After someone signs in, the app needs to remember them on every following request. Two common approaches:

• Session cookie. The server creates a session and gives the browser a random ID in a cookie. Each request sends the cookie; the server looks up the session. Logging out deletes the session.
• Token (often a JWT). The server gives the app a signed token that contains who the user is and when it expires. Each API request sends it, usually in an Authorization: Bearer … header. The server checks the signature instead of looking anything up.

Both are fine when done well. What matters for product decisions:

• How long do sessions last? "Stay signed in for 30 days" is convenient; banking apps choose minutes.
• Can we sign someone out everywhere? Needed after a password change or a stolen laptop. Pure tokens are harder to revoke before they expire, so teams add short expiry plus refresh tokens.
• What happens when a session expires mid-task? Losing a half-written form is a product bug, not only a technical one.

OAuth and OpenID Connect in one paragraph

OAuth 2.0 lets a user give an app limited access to their account somewhere else without sharing the password — "Allow this app to read your calendar". OpenID Connect (OIDC) is a layer on top of OAuth used for signing in — "Continue with Google". When engineers mention scopes, they mean the specific permissions requested (read calendar vs. manage calendar). Asking for fewer scopes means fewer scary consent screens and less risk.

Authorization: roles and permissions

Once you know who someone is, you decide what they can do. Common models:

• Ownership: you can edit what you created.
• Roles (RBAC): Owner, Admin, Editor, Viewer — each role has a set of permissions.
• Per-resource sharing: this document is shared with these three people.
• Attribute-based rules: managers can approve expenses under $5,000 in their own department.

The most important technical rule: authorization must be enforced on the server (or in database rules), not only by hiding buttons in the UI. Hiding the "Delete" button is good UX; it is not security. Anyone can send the request directly.

A classic bug, often called IDOR (insecure direct object reference): the app loads /api/invoices/1042 for a logged-in user but never checks that invoice 1042 belongs to them. Change the number in the URL and you see someone else's invoice.

What engineers may tell you

• "The token expired, so the refresh flow kicked in." The app silently got a new short-lived token using a longer-lived refresh token.
• "That check only exists on the frontend." The permission is not really enforced; it must move to the server.
• "Enterprise SSO is per-tenant configuration." Each customer's identity provider has to be connected and tested separately.
• "We need to rate-limit the login endpoint." Without it, attackers can try thousands of passwords.
• "We shouldn't say whether the email exists." Different messages for "wrong password" and "no such user" let attackers discover who has an account.

Questions a good technical PM asks

1. Which sign-in methods do we support, and why those?
2. How long do sessions last, and can a user sign out of all devices?
3. What is the account recovery flow if someone loses access to their email or second factor?
4. Where is each permission enforced — server, database rules, or only the UI?
5. What roles exist, and who can change someone's role?
6. Do we log important security events (sign-ins, role changes, exports)?
7. What does a user see when their session expires in the middle of work?

Red flags

• Passwords stored in plain text, or "we can email you your password".
• Permission checks only in the frontend.
• Admin features protected by an unguessable URL instead of a real role check.
• No rate limiting on login, sign-up or password reset.
• Tokens or session IDs placed in URLs, where they end up in logs and browser history.
• Account deletion that leaves the user's data behind — or deletes other people's shared data.

Using an AI coding agent for auth

Ask the agent to use an established auth provider or library rather than inventing one, and be explicit about authorization:

Use the existing auth provider for sign-in (email link + Google).
Authorization rules:
- A user can read and edit only projects where they are a member.
- Only the project owner can delete a project or change member roles.
Enforce these rules on the server / in database security rules, not only in the UI.
Add tests that prove a non-member gets 403 when reading another project by ID.

Then test it like an attacker would, gently: open a record as user A, copy its URL, sign in as user B and paste it. If B can see it, the authorization is missing.

Try it yourself

Pick one feature in your product and write a tiny permission table: rows are actions (view, create, edit, delete, invite), columns are roles (owner, admin, member, guest). Fill in yes/no. You will probably find at least one cell nobody has decided — and that is exactly the conversation to have with your engineers.

In the TechPMer course, week 7 (“Data & User Accounts”) adds real sign-in and data security rules to your own project with an AI coding agent, including a review checklist.