Identification vs. authentication vs. authorization

Identification is presenting an identifier (a username) so the system can recognize you. Authentication is verifying that claim (a password, biometric, or token). Authorization is the approval that lets the authenticated entity access a resource. They are distinct steps: identify, authenticate, then authorize.[1][2][3]

Access control models

DAC (the owner decides who gets access), MAC (a central authority enforces access using labels and clearances; military security is the classic example), RBAC (privileges attach to pre-defined roles that subjects are assigned), ABAC (rules evaluated against subject, object, operation, and environment attributes), and rule-based access control (global rules imposed on all users). Know which model fits which scenario.[4][5][6][7][8]

Multi-factor authentication

Something you know, something you have, something you are: genuine MFA requires more than one distinct type of factor. Two passwords are both something you know, so they are not MFA, no matter how complex either is.[9][10]

Federation and SSO

SAML, OAuth 2.0, and OpenID Connect solve different problems. SAML defines XML-encoded assertions about authentication, attributes, and authorization and is a widely used federation protocol for SSO. OAuth 2.0 is authorization delegation: an app gets limited access with its own credentials instead of the user's password. OpenID Connect is an identity layer on top of OAuth 2.0 that adds authentication. SSO means one account and its authenticators reach many applications, generally through a federation protocol.[11][12][13][14][15][16]

Kerberos

Ticket-based authentication using a trusted third party (the Key Distribution Center, KDC). The client first obtains a Ticket Granting Ticket (TGT) and uses it with the ticket-granting server to get service tickets. Know the attacks on those tickets: a golden ticket is a TGT forged with the KRBTGT account's password hash, and a silver ticket is a service (TGS) ticket forged with a service account's hash.[17][18][19][20]

OAuth 2.0 vs. OpenID Connect

OAuth 2.0 is about authorization ("can this app access my data"), not authentication ("who is this user"). OpenID Connect is the identity layer built on top of OAuth 2.0 that lets the client verify the user's identity, so when the goal is logging a user in, OpenID Connect is the answer, not OAuth 2.0 alone.[14][15][16]

RBAC vs. ABAC

RBAC grants permissions through pre-defined roles (simple, but dynamic decisions can require many ad hoc roles, the problem called role explosion). ABAC evaluates rules against subject, object, operation, and environment attributes at request time: more flexible, but the components needed to run it get more complex across an enterprise.[6][7][21][22]