Verifying the account–authenticator binding
A claimant produces protocol output, and a verifier checks it against authenticators bound to an active account. A password check or a private-key response to a challenge supplies different evidence that the claimant can act as that account.
Enrollment identity proofing establishes an initial association; later authentication checks authenticator control rather than merely accepting a typed name. The resulting identifier may be pseudonymous, and recognition of the account does not itself authorize every operation.
References: [1]
Several steps need not mean several factors
Common factors are something known, possessed or inherent to the person, such as a password, a key-bearing device or a biometric. A password plus a user-chosen PIN can remain one factor type; counting input screens does not establish multifactor authentication.
Phishing resistance is separate. NIST notes that manually entered one-time outputs can be relayed by an impostor. Resistant mechanisms bind output to the channel or verifier identity, so more factors alone do not establish resistance to relay-based phishing.
A session carries an authentication forward
A service commonly establishes a session after authentication, using a session secret or proof of its possession for later requests instead of repeatedly presenting the original authenticator. A browser cookie can carry short-term session state without being the original password or device.
Logout, timeouts and reauthentication govern continuity. Repeating some or all authentication can renew assurance, but refreshing a page or retaining a cookie longer cannot by itself raise the authentication assurance level.
References: [2]