Authentication answers the question, “Who is making this request?” A person, application, or device claims an identity and presents evidence that a trusted system validates. That evidence might be a password, a cryptographic signature, a security key, or a token issued by a trusted identity provider. Authentication establishes confidence in an identity; it does not automatically establish that a request is permitted.
Authentication and authorization are separate decisions. An engineer might successfully sign in to a cloud console but receive an access-denied response when attempting to delete a database. The sign-in established the engineer’s identity, while authorization policies rejected the requested action. For exam questions, credentials and identity verification generally indicate authentication, while permissions, policies, and allowed actions indicate authorization.
Cloud platforms authenticate both human users and workloads. People commonly use an interactive sign-in process with multifactor authentication, or MFA. Applications typically use temporary credentials, signed requests, certificates, or tokens rather than interactive passwords. For example, an application running on a virtual machine can obtain temporary credentials through an attached workload role instead of storing a permanent secret in its source code.
In AWS, IAM users can have passwords for console access and access keys for programmatic access. These are different credentials: a console password is not used to sign AWS CLI requests. AWS API requests commonly use Signature Version 4, which proves possession of the secret access key without transmitting that secret in the request. Temporary AWS credentials also include a session token and expire after a defined period.
Roles provide assumable identities with permissions and are commonly used with temporary credentials. An IAM group is different: it organizes IAM users for permission management and cannot sign in or authenticate independently. The AWS account root user is also distinct from an IAM user. Protect root access with MFA, avoid using it for routine work, and avoid creating root access keys.
MFA requires evidence from different factor categories, such as something a user knows and something the user possesses. Two passwords do not constitute two factors. Phishing-resistant methods, such as appropriately implemented FIDO security keys or passkeys, provide stronger protection against credential phishing than passwords combined with manually entered one-time codes. MFA does not grant permissions or make an already issued session immune to theft.
Federation lets a cloud platform trust authentication performed by an external identity provider. An employee can sign in through a corporate identity system and obtain a cloud session without maintaining a separate long-lived cloud password. Single sign-on improves usability and centralizes identity administration, but the identity provider becomes a critical dependency that requires strong security and recovery procedures.
Authentication design balances security, usability, and operational complexity. Short-lived credentials reduce the useful lifetime of stolen credentials but require reliable renewal. Long-lived secrets require secure storage, rotation, and revocation. Engineers should avoid shared identities, prevent credentials and tokens from entering logs or repositories, and monitor sign-in and API activity. Disabling an account or changing a password does not necessarily invalidate every existing session immediately; session expiration and revocation behavior must be understood separately.
Amazon Cognito