Cybersecurity / Basic: defensive concepts and personal-service boundaries / Lesson 2

Identity, authentication, and account lifecycle

Separate identifying a subject, proving control of an authenticator, and granting permission to act.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish identity proofing, authentication, authorization, and session state.
Plan account creation, review, and retirement.

Define the subject and the service relationship

An account represents a subject within a service, but its name alone does not establish the person or organization behind it. Identity proofing establishes attributes to a chosen level of confidence; authentication checks control of an authenticator; authorization decides allowed actions. A service can need different assurance for reading public lessons and changing private records. Define the purpose and consequences before choosing mechanisms. Avoid collecting extra identity documents merely because more data feels safer: unnecessary collection introduces privacy and retention risk that the service must then manage.

Treat authentication as a claim with limits

An authenticator may involve a memorized secret, a device-held cryptographic key, or another supported factor. Successful authentication supports a bounded claim about control at that moment; it does not guarantee every later action is authorized or that the endpoint is uncompromised. Use approved libraries and identity services rather than inventing a login protocol. Account recovery and factor replacement are part of the same security boundary. A strong sign-in mechanism can be undermined if a help process resets it using weak or easily obtained information. Review the whole lifecycle, not only the login screen.

Make account ownership and review visible

Each human and service account should have a purpose, accountable owner, expected permissions, and a review or expiry process. Shared staff accounts weaken attribution and complicate departure handling. Service accounts need ownership even when no person signs in interactively. The example is a fictional lifecycle record, not a directory configuration or a command to create users. It contains no password or real identifier. A real identity system enforces these decisions through supported provisioning and access controls, while the record explains why the account exists and who resolves uncertainty.

json A synthetic account-lifecycle record

{
  "account": "lab-course-editor",
  "type": "human",
  "ownerRole": "content-maintainer",
  "purpose": "edit assigned lessons",
  "accessProfile": "limited-editor",
  "reviewState": "scheduled",
  "departureAction": "approved-access-removal"
}

The file is an application-defined planning example and provisions nothing. It deliberately omits credentials. A real account inventory should use stable identifiers with appropriate access protection and retention.

Keep session validity separate from permission

After authentication, a session can represent continuing access under expiry, revocation, and device conditions. Recheck permission at the protected operation rather than trusting that a user once logged in. Sensitive actions may require a fresh or stronger authentication step under policy. The pure function below only classifies synthetic session facts. It is not session-token validation, does not process a cookie, and must not be connected directly to a real authorization boundary. Real validation requires trusted server-side state or verified tokens with correct issuer, audience, lifetime, and revocation handling.

python A local session-decision teaching model

def session_review(facts):
    if facts.get("revoked") is True:
        return "access-not-valid"
    if facts.get("expired") is True:
        return "authenticate-again"
    if facts.get("validated") is not True:
        return "validation-required"
    return "check-operation-permission"

assert session_review({"validated": True}) == "check-operation-permission"

The final result still calls for authorization. The booleans are pre-declared lab facts, not proof supplied by a client. No account, token, or service is inspected or changed.

Review changes and retire access deliberately

Role changes, staff departure, lost devices, and compromised authenticators can require access review, session revocation, and recovery actions by authorized owners. The exact order depends on risk and operational responsibilities; a generic script cannot safely replace the process. Verify that disabled access really stops the intended actions and that service dependencies remain understood. Keep a minimal audit trail without storing authentication secrets. NIST digital identity guidance supplies technical concepts and requirements for its defined scope; using one recommendation does not establish that a portal satisfies an assurance level or any legal obligation.

Common errors and fixes

Login success grants every action

Why it happens: Authentication is confused with authorization.
How to fix it: Check permission for each protected operation.
Prevent it next time: Design separate authentication and access tests.

An old staff account remains active

Why it happens: Lifecycle ownership and departure steps are missing.
How to fix it: Use the approved owner-led access review process.
Prevent it next time: Tie accounts to purpose and review events.

Recovery bypasses strong authentication

Why it happens: The reset path uses weaker evidence than sign-in.
How to fix it: Review recovery assurance and factor replacement controls.
Prevent it next time: Include recovery in identity design and exercises.

Check your understanding

1. A user can authenticate but is not assigned to a lesson. What should decide edit access?

Show worked solution

The service’s authorization policy for that subject, resource, and action. Authentication identifies a validated session context but does not create an assignment. The server must enforce the rule even if the interface hides the button.

2. A background export account has no interactive login. Does it still need an owner?