Inno 3.12 Auth Flashcards
(21 cards)
Authentication
Determines whether users are who they claim to be
Challenges the user to validate credentials (for example, through passwords, answers to security questions, or facial recognition)
Difference between Authentication and Authorization
Authentication verifies the identity of a user, while authorization determines what access an authenticated user has to resources.
Authentication comes first, and successful authentication is a prerequisite for authorization. Think of it as authentication is like answering the question “Who are you?”, and authorization is like answering “What can you do?
Authorization
Determines what users can and cannot access
Verifies whether access is allowed through policies and rules
What is the structure of a JSON Web Token (JWT)?
A JWT consists of three parts: Header, Payload, and Signature, separated by dots. The header typically includes the type of token (JWT) and the signing algorithm (e.g., HS256, RS256). The payload contains claims (like user ID, roles, or expiration). The signature is created by signing the header and payload with a secret or private key. This structure ensures token integrity and authenticity.
HEADER (type of token and signing algorithm) + PAYLOAD (claims) + SIGNATURE (secret or private key)
How does the JWT authentication flow work?
In a typical JWT flow, a user logs in and receives a signed JWT from the authentication server. The client stores this token (often in localStorage or a secure cookie) and includes it in the Authorization header of future requests.
The server validates the token’s signature and checks its claims (like expiration). If valid, access is granted without storing session state. This enables stateless authentication.
How is a JWT signed and what algorithms are commonly used?
A JWT is signed to ensure that it hasn’t been tampered with. Common algorithms include HS256 (HMAC using SHA-256) and RS256 (RSA signature with SHA-256). HS256 uses a shared secret key, while RS256 uses a private/public key pair. The signature is created from the encoded header and payload, and any changes to the token invalidate the signature. Choosing the right algorithm balances security and performance.
What are claims in a JWT?
Claims are key-value pairs in the JWT payload that convey information about the user or token. There are three types: registered (e.g., iss, exp, sub), public (standardized but optional), and private (custom claims specific to your app). For example, sub might store the user ID, and exp defines the expiration time. Claims allow the server to understand the context of the request.
How is JWT configured in applications?
JWT configuration involves setting up token generation and validation logic. You define secret keys or certificates, token lifetime, claims to include, and which algorithm to use.
In frameworks like ASP.NET, middleware like JwtBearer handles automatic validation. It’s important to keep secrets secure and configure token expiration and issuer validation to prevent misuse.
What are JWT best practices for security?
Always use HTTPS to prevent token interception.
Set a short token lifetime to limit exposure and use refresh tokens to extend sessions securely.
Consider blacklisting tokens (e.g., on logout) to invalidate tokens early.
Store tokens securely—preferably in HttpOnly cookies for protection against XSS. Never store tokens in localStorage if you can avoid it.
Why is using HTTPS important when working with JWTs?
HTTPS encrypts data in transit, preventing attackers from sniffing JWTs from network traffic. Without HTTPS, tokens sent in headers or cookies can be stolen via man-in-the-middle (MITM) attacks.
Since JWTs often grant direct access, exposure can lead to account hijacking. Securing the transport layer is fundamental to protecting any kind of sensitive token or credential.
Why should JWTs have a short lifetime?
A short token lifetime limits the window in which a stolen token can be used.
If a JWT is compromised, an expiration of just a few minutes reduces potential damage. Combined with refresh tokens, users can still enjoy seamless experiences. This also encourages regularly validating the user’s identity and access rights.
What are refresh tokens and how do they work?
Refresh tokens are long-lived tokens used to obtain new access tokens without requiring the user to log in again. They’re typically stored securely (e.g., HttpOnly cookies) and sent only to the token endpoint. When the short-lived access token expires, the client sends the refresh token to get a new one. Refresh tokens should be securely stored and revocable to minimize security risks.
How does token blacklisting improve security?
Blacklisting involves maintaining a list of invalidated tokens—usually upon logout, password change, or suspicious activity.
Since JWTs are stateless and don’t need to check a central store, blacklisting is an extra step to enforce revocation.
This can be done using a database or in-memory store. It allows for immediate invalidation of tokens instead of waiting for expiry.
What are cookies and how are they structured?
Cookies are small pieces of data stored in the browser and sent with HTTP requests to the same server.
A cookie consists of a name-value pair and optional attributes like Expires, Path, Domain, Secure, and HttpOnly.
They’re commonly used to store session identifiers, tokens, or preferences. Cookies must be carefully configured to avoid security vulnerabilities.
What are the different types of cookies?
Session cookies are temporary and deleted when the browser is closed.
Persistent cookies remain on the device for a specified duration.
Secure cookies are only sent over HTTPS connections.
HttpOnly cookies are inaccessible via JavaScript and help prevent XSS attacks.
Using these types appropriately helps enhance the security and behavior of your app.
What is a session cookie?
A session cookie is a non-persistent cookie that exists only while the browser session is active. It’s deleted automatically when the browser is closed. They’re useful for short-term state like logged-in status or cart data. Since they don’t persist on the client, they’re less likely to be exploited over long periods.
DELETED WHEN BROWSER IS CLOSED
What is a persistent cookie?
A persistent cookie remains stored on the user’s device even after the browser is closed. It has an expiration date set via the Expires or Max-Age attribute. These are used for “remember me” features or analytics tracking. However, they can pose security risks if misused or not expired properly.
REMAINS STORE ON THE USERS DEVICE AFTER BROWSER IS CLOSE, HAS EXPIRY DATE
What is a secure cookie and why use it?
A secure cookie is only sent to the server over HTTPS connections. This prevents the cookie from being exposed in unencrypted traffic. It should be used for any cookie that holds sensitive data, like authentication tokens. Enabling this attribute is essential in production environments to avoid MITM attacks.
ONLY SENT OVER HTTPS CONNECTIONS
What is an HttpOnly cookie?
An HttpOnly cookie cannot be accessed via JavaScript, protecting it from XSS attacks. It’s set by the server with the HttpOnly flag and is still automatically sent in HTTP requests. This makes it ideal for storing authentication tokens or session IDs. It’s a simple and effective way to boost security for web apps.
CANT BE ACCESS BY JAVASCRIPT
How does account confirmation work in web applications?
Account confirmation typically involves sending an email with a unique confirmation link after registration. The user must click the link to verify their ownership of the email address. This step helps prevent fake or mistyped accounts. The link includes a token that’s validated by the server to activate the account.
LINK ICLUDES TO TOKEN VALIDATED BY THE SERVER TO ACTIVATE ACCOUNT
What are external logins and how are they used?
External logins allow users to authenticate using third-party providers like Google, Facebook, or Microsoft. Instead of handling passwords, your app relies on OAuth/OpenID Connect flows to obtain user identity information.
This simplifies onboarding and improves security by delegating authentication to trusted providers. External logins are common in modern apps to streamline sign-in.
