Auth
Authentication
Authentication can be based on one or more of the following:
- Something the user knows (password, PIN, pattern, etc.)
- Something the user has (SIM card, one-time password generator, or hardware token)
- A biometric property of the user (fingerprint, retina, voice)
the server and client need to keep track of user data (e.g., the user's privileges or role). This can be done in two different ways:
- With stateful authentication, a unique session id is generated when the user logs in. In subsequent requests, this session ID serves as a reference to the user details stored on the server. The session ID is opaque; it doesn't contain any user data.
- With stateless authentication, all user-identifying information is stored in a client-side token. The token can be passed to any server or micro service, eliminating the need to maintain session state on the server. Stateless authentication is often factored out to an authorization server, which produces, signs, and optionally encrypts the token upon user login.
Web applications commonly use stateful authentication with a random session ID that is stored in a client-side cookie. Although mobile apps sometimes use stateful sessions in a similar fashion, stateless token-based approaches are becoming popular for a variety of reasons:
- They improve scalability and performance by eliminating the need to store session state on the server.
- Tokens enable developers to decouple authentication from the app. Tokens can be generated by an authentication server, and the authentication scheme can be changed seamlessly.
Stateful Authentication
Stateful (or "session-based") authentication is characterized by authentication records on both the client and server. The authentication flow is as follows:
- The app sends a request with the user's credentials to the backend server.
- The server verifies the credentials. If the credentials are valid, the server creates a new session along with a random session ID.
- The server sends to the client a response that includes the session ID.
- The client sends the session ID with all subsequent requests. The server validates the session ID and retrieves the associated session record.
- After the user logs out, the server-side session record is destroyed and the client discards the session ID.
- When sessions are improperly managed, they are vulnerable to a variety of attacks that may compromise the session of a legitimate user, allowing the attacker to impersonate the user. This may result in lost data, compromised confidentiality, and illegitimate actions.
Stateless Authentication
Token-based authentication is implemented by sending a signed token (verified by the server) with each HTTP request. Most commonly, these are JWTs
Best Practices
- Verify that the HMAC is checked for all incoming requests containing a token.
- Verify that the private signing key or HMAC secret key is never shared with the client. It should be available for the issuer and verifier only.
- Verify that no sensitive data, such as personal identifiable information, is embedded in the JWT. For example, by decoding the base64-encoded JWT and find out what kind of data it transmits and whether that data is encrypted. If, for some reason, the architecture requires transmission of such information in the token, make sure that payload encryption is being applied.
- Make sure that replay attacks are addressed with the jti (JWT ID) claim, which gives the JWT a unique identifier.
- Make sure that cross service relay attacks are addressed with the aud (audience) claim, which defines for which application the token is entitled.
- Verify that tokens are stored securely on the mobile phone, with, for example, KeyChain (iOS) or KeyStore (Android).
- Verify that the hashing algorithm is enforced. A common attack includes altering the token to use an empty signature (e.g., signature = "") and set the signing algorithm to none, indicating that "the integrity of the token has already been verified". Some libraries might treat tokens signed with the none algorithm as if they were valid tokens with verified signatures, so the application will trust altered token claims.
- Verify that tokens include an "exp" expiration claim ↗ and the backend doesn't process expired tokens. A common method of granting tokens combines access tokens and refresh tokens ↗. When the user logs in, the backend service issues a short-lived access token and a long-lived refresh token. The application can then use the refresh token to obtain a new access token, if the access token expires.
Authorization vs Authentication
Because "auth" is ambiguous, we often see the distinguishing terms "authn" (authentication) and "authz" (authorization)
Both are an important part of identity and access management (IAM), but...
- authn has to do with identity (who someone is)
- authn can be carried out with username/password, 2FA, public key certificates, biometric etc.
- authz has to do with permissions (what an authenticated user is allowed to do)
- authz can be carried out with RBAC (role-based access control), ABAC (attribute-based access control)
anal: think of authorization as a subway ticket. The ticket is in no way attached to your identity, since you just got it from the machine. You could give this ticket to someone else, and it would authorize them to enter the platform and board the train. Authentication on the other hand, is about identity. If Authorization is a subway ticket, then Authentication is a finger print scan.
Basic Authentication
HTTP provides its own form of basic authentication out of the box. It works by combining the username and password with a : separator, then base64 encoding the string.
- dangerous, since we are passing the password on every request.
Because of SSL, sending plaintext passwords from the client to the server is perfectly fine.
UE Resources
Children
Backlinks