Authentication: How a System Checks Who You Are

Authentication is how a system checks a claim about who is signing in. Authorisation is what that account is allowed to do once it gets there. A business leader needs to understand both.

I would start with an ordinary situation. A new colleague can sign in to the company portal but cannot open a confidential forecast. That may be the system working exactly as intended. A successful login should not open every door.

What the sign-in is checking

An account name tells the system which account you claim. An authenticator supplies evidence that you control it: perhaps a password, a security key or a passkey. NIST's authentication guidance describes this as checking control of authenticators associated with an account. It is not a guarantee about a person's honesty or their permission to make a business decision.

Single sign-on, often called SSO, lets applications rely on an organisation's sign-in service. It can make account administration more coherent. It does not automatically give every application the same permissions. OWASP's authentication guidance explains the identity-provider approach.

After signing in, a session lets the application recognise subsequent requests. OWASP's session guidance explains why that continuing access also needs protection. Closing a window is not a reliable company-wide offboarding process.

Three questions for a system owner

If my team were adopting an application, I would ask:

• Who owns sign-in? Is it our approved work identity or another account someone created individually?
• Who grants access? What can a normal user see, change, export and share? Can we demonstrate the restrictions with test accounts?
• Who removes it? What happens to existing sessions, connected tools and recovery methods when somebody leaves?

These are proposed management questions, not an assessment of your current system. The administrator needs to establish what the particular product actually does.

For software accounts used by integrations or agents, ask the same questions about the account's owner and scope. A bot with valid credentials still needs appropriate permissions. Telling it to behave is not an access-control setting.

Try the distinction with invented people

Imagine this fictional setup:

Alex cannot open the draft forecast. First check the intended permission. Do not solve every access-denied message by granting administrator rights.

Taylor's case needs evidence of removal, including any continuing sessions or connected credentials that require separate revocation. Removing a name from a team list alone does not establish that every route has been closed.

Ask your AI to teach you

Use an AI tool your organisation permits for learning. This exercise needs no real accounts or company information. Paste this:

A useful tutor makes you explain why Alex's denied request might be correct. It should not ask you to paste a login code or offer to fix the real account. The instruction itself cannot enforce these limits: keep account connections and action tools out of this exercise.

Check that you can use it

Explain this in your own words: “We know which account signed in. We still need to decide what it may do.” Then describe how you would check that a departing contractor's access has ended.

Your next practical step is to ask the owner of one approved work application to explain its sign-in and access-removal process. Discuss the process; this lesson does not authorise changing it.

Read the existing authorisation guide next, followed by passwords, passkeys and second factors.

Sources and boundaries

Sources checked on 21 October 2026: NIST and the two OWASP guides linked above. The account table, supplier questions and tutor exercise are proposed teaching examples, not a tested course, security audit or statement about your employer's configuration. Use the sources to check the AI's explanation.