Test your understanding of authentication versus authorization, including session and token differences, JWT and opaque token features, and core OAuth2 concepts. Perfect for anyone wanting to solidify foundational knowledge of AuthN, AuthZ, and modern security protocols.
Which process verifies a user's identity before granting access to a system?
Explanation: Authentication confirms who a user claims to be, such as checking a username and password. Authorization is about determining what resources the authenticated user can access. 'Authetication' and 'Attronization' are misspellings and not valid security terms. Only 'Authentication' directly addresses the process of identity verification.
Which approach typically stores an access credential on the client side to be sent with each request: sessions or tokens?
Explanation: Tokens—such as JWTs—are usually stored on the client and included in each request, enabling stateless authentication. Sessions often store credentials server-side, using a session ID passed by the client. 'Tokenss' and 'Sessons' are typographical errors and not correct terms. Therefore, 'Tokens' is the best choice.
What is a key characteristic of a JWT (JSON Web Token) compared to an opaque token?
Explanation: JWTs include encoded information, or 'claims', that can be decoded and read without a secret. JWTs are not always encrypted—by default, they are only encoded and signed. They are commonly sent via headers, and JWTs have digital signatures to ensure integrity. Opaque tokens, on the other hand, have no readable internal structure.
When using an opaque access token, what does the application typically know about its content directly?
Explanation: Opaque tokens do not expose any internal data to clients; only the issuing server can interpret them. Unlike JWTs, the application cannot extract or view user roles or usernames directly from opaque tokens. Such tokens never store passwords. Only the first option describes this accurately.
Which OAuth2 flow is most suitable when a traditional web application needs to access resources on behalf of an authenticated user?
Explanation: The Authorization Code flow is secure and commonly used by server-side web apps when acting on behalf of users. The Client Credentials flow is used for machine-to-machine communication without end-user involvement. Resource Owner and Implicit flows are less secure or have limited use cases in this scenario.
If an OAuth2 access token's scope includes 'read:profile', what does this indicate?
Explanation: Scopes define what actions or resources a token holder can access; 'read:profile' means reading profile data. The other options are incorrect, as the scope limits write/access, not uploads or unrestricted actions. Editing profiles or lack of restrictions are not implied by this scope.
What is a common reason for expiring a user session after a period of inactivity?
Explanation: Closing inactive sessions helps prevent unauthorized access if someone leaves a device unattended. Expiry does not affect website speed, user’s ability to use various passwords, or advertising costs. Only the first option addresses a valid security practice related to sessions.
When does authorization happen in a typical application workflow?
Explanation: Authorization checks occur after the user is authenticated to decide what they are allowed to access. The other options do not relate to access control. For example, authorization does not concern internet speed, password creation, or email verification.
Why are tokens commonly considered 'stateless' in authentication systems?
Explanation: Statelessness comes from the server not having to remember any session data; all information is encoded within the token. Tokens seldom need to be regenerated or always encrypted. A database lookup is unnecessary for JWTs, and not all tokens are unreadable. The first answer is correct.
Which of these is most commonly used as a session identifier stored in browser cookies?
Explanation: Sessions typically use random, unpredictable strings to minimize security risks if intercepted. Storing a hashed password, username, or a refresh token as the session ID is insecure and not standard practice. The random string serves only as a reference to session data on the server.