The document discusses user authentication and cookies within backend technologies, focusing on basic authentication methodologies, their pros and cons, and best practices for secure implementation. It highlights how cookies function, their types, attributes, and security considerations needed to protect user data. The conclusion recommends using secure connections and combining basic authentication with other security measures, as well as considering more secure token-based authentication methods.

1. 1
DISCOVER . LEARN . EMPOWER
UNIT-3
UNIVERSITY INSTITUTE OF COMPUTING
MASTER OF COMPUTER APPLICATIONS
Backend Technologies
23CAH-705

2. 2
User Authentication
• Basic Authentication, Cookies,
Tea, err, Express session, Passport
• Token based authentication,
Mongoose population
Backend Technologies
CO
Number
Title Level
CO3 Understand the working of Git to upload the created
project
2.1.3, 3.1.1
CO4 Apply the CRUD operations of MongoDB in the
development of website
3.1.1, 3.4.3
Course Outcome

3. Basic Authentication
Basic Authentication is a simple authentication scheme built into the HTTP protocol. It
involves sending credentials in the form of a username and password to the server, which
then validates these credentials and grants access to the requested resource if they are
correct.
Here's a high-level overview of how Basic Authentication works:
• Client Request: The client (usually a web browser or API client) requests a resource
from the server.
• Server Response: The server responds with a 401 Unauthorized status code and
includes a WWW-Authenticate header indicating that Basic Authentication is required.
• Client Submits Credentials: The client resends the request, this time including an
Authorization header with the credentials. The credentials are formatted as
username:password and then Base64 encoded.
• Server Validation: The server decodes the Base64 encoded string, verifies the
credentials, and grants access to the resource if the credentials are valid.
3

4. 4
Example
• Client Request Without Credentials
GET /protected-resource HTTP/1.1
Host: example.com
• Server Response Requesting Authentication
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Access to the protected
resource"

5. 5
• Client Request With Credentials
GET /protected-resource HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
In this example, dXNlcm5hbWU6cGFzc3dvcmQ= is the Base64 encoded
form of username:password.

6. 6
Pros and Cons
Pros
• Simplicity: Easy to implement and use.
• Compatibility: Supported by virtually all web clients and servers.
• Statelessness: Fits well with the stateless nature of HTTP.
Cons
• Security: Credentials are Base64 encoded, not encrypted. They can be easily
decoded if intercepted.
• Weak Against Replay Attacks: Since the credentials are the same for each request,
they can be captured and reused by attackers.
• Plain Text Transmission: Should always be used over HTTPS to prevent credentials
from being exposed over the network.

7. 7
Usage Best Practices
• Always Use HTTPS: Encrypt the entire HTTP message to protect the credentials
during transmission.
• Use Strong Passwords: Ensure that the passwords used are strong and complex.
• Combine with Other Security Measures: Use in conjunction with other security
mechanisms such as IP whitelisting, rate limiting, and account lockout policies.
Conclusion
• While Basic Authentication is easy to implement and widely supported, it should
be used with caution and always over a secure connection (HTTPS) due to its
inherent security weaknesses. For more secure authentication methods,
consider using token-based authentication schemes like OAuth or JWT.

8. 8
Cookies
Cookies are small pieces of data that a server sends to a user's web browser. The
browser may store these cookies and send them back to the same server with
subsequent requests. Cookies are used for various purposes, including session
management, user personalization, and tracking.
Types of Cookies
1. Session Cookies:
• Lifetime: Temporary and deleted when the browser is closed.
• Use Case: Used for maintaining user sessions during a single visit to a website.
2. Persistent Cookies:
• Lifetime: Remain on the user's device for a specified period or until they are deleted.
• Use Case: Used for remembering login details and user preferences across multiple visits.

9. 9
3. First-party Cookies:
• Source: Set by the website the user is visiting.
• Use Case: Used for maintaining session information, storing user preferences,
and other purposes directly related to the user's interaction with the site.
4. Third-party Cookies:
• Source: Set by domains other than the one the user is visiting.
• Use Case: Commonly used for advertising and tracking purposes across
different websites.

10. 10
How Cookies Work
1. Setting a Cookie:
• When a user visits a website, the server sends an HTTP response with a Set-Cookie header.
Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2024 07:28:00 GMT;
Path=/; Secure; HttpOnly
2. Storing a Cookie:
• The browser stores the cookie and associates it with the domain that set it.
3. Sending a Cookie:
• On subsequent requests to the same domain, the browser includes the cookie in the HTTP
request headers.
Cookie: sessionId=abc123

11. 11
Cookie Attributes
• Name=Value: The data stored in the cookie. This is the only required attribute.
• Expires: Specifies when the cookie should expire. If not set, the cookie is a session cookie.
• Max-Age: Specifies the maximum age of the cookie in seconds.
• Domain: Specifies the domain that can access the cookie. Defaults to the domain that set the
cookie.
• Path: Specifies the URL path that must exist in the requested URL for the browser to send the
cookie.
• Secure: Indicates that the cookie should only be sent over secure connections (HTTPS).
• HttpOnly: Prevents the cookie from being accessed via JavaScript, providing some protection
against cross-site scripting (XSS) attacks.
• SameSite: Controls whether the cookie is sent with cross-site requests, providing some
protection against cross-site request forgery (CSRF) attacks. Values can be Strict, Lax, or None.

12. 12
Security Considerations
1. Secure Attribute:
• Always use the Secure attribute for cookies containing sensitive data to ensure
they are only sent over HTTPS.
2. HttpOnly Attribute:
• Use the HttpOnly attribute to prevent JavaScript access to cookies, mitigating XSS
attacks.
3. SameSite Attribute:
• Use the SameSite attribute to prevent CSRF attacks by restricting how cookies are
sent with cross-site requests.
4. Encryption:
• For highly sensitive information, consider encrypting the data stored in cookies.

13. 13
Practical Example
1. Setting a Cookie in a HTTP Response
HTTP/1.1 200 OK
Set-Cookie: userId=789xyz; Expires=Fri, 12 Jul 2024 07:28:00
GMT; Path=/; Secure; HttpOnly; SameSite=Lax
2. Sending a Cookie in a HTTP Request
GET /dashboard HTTP/1.1
Host: example.com
Cookie: userId=789xyz

14. 14

15. 15

16. 16

17. 17

18. 18

19. 19

20. 20
References
• https://www.amazon.in/Full-Stack-JavaScript-Development-MEAN/dp/0992461
251
• https://books.google.co.in/books/about/Full_Stack_React_TypeScript_and_No
de.html?id=uUMQEAAAQBAJ&redir_esc=y
• https://hub.packtpub.com/web-development-react-and-bootstrap/
• https://www.oreilly.com/library/view/pro-mern-stack/9781484243916/

21. THANK YOU
21