Skip to content

Authentication

jwberck edited this page May 5, 2017 · 9 revisions

Authentication is the process of verifying the identity of an entity (“Authentication Cheat”, 2017). In web applications authentication is commonly carried out by submitting a user name and password. Additional information that only the user would know is sometimes required. Without authentication malicious users can manipulate or steal data, making its implementation a high priority in the majority of applications.

Cookie Based

Conceptually, a cookie is just an item in a dictionary stored in the client. A signed cookie is a cookie that is encrypted by a server, meaning only that server can use it in the client’s dictionary.

Cookie based authentication is stateful, meaning that a session must be tracked on the server and client to authenticate a user. Cookie based authentication usually follows these steps as shown in "Cookie Based Authentication":

1 Signup: The client posts an HTTP request containing the users sign up information. Then, the server encrypts the password and stores the user information in a database.

2 Login: The client posts another HTTP request with the user login information. This time, the server looks up the user in the database, encrypts the password, and compares it to the stored password. If this fails, then the server denies the client access.

3 Generate session access token: After successfully logging in, the server creates a unique access token to identify the user. First the server stores this token in the database with the user information, then it is attached to a cookie and sent to the client.

4 Making server requests: Once the user is logged in and has a session cookie stored, they can make requests to the server that require authorization. Each time the client makes a request, the cookie is attached to that request. If the request requires authorization, then the server checks the access token against the one in the database. If they match, access is granted.

5 Logout: When the user logs out, the session is destroyed on the client and server. (Patrick, 2014)

Cookie Based Authentication (Sevilleja, 2015) Server Based Authentication

JSON Web Token (JWT)

In JSON Web Token (JWT) systems, the server doesn’t keep a record of who is logged in or what tokens have been issued. The tokens are self-contained, meaning that they carry all necessary information inside of themselves in the form of standardized JSON data.

When a user first logs in with their credentials, the server will create a JWT and return it to the user as shown in "JWT Based Authentication". Then, the user stores this token locally or as a cookie and uses it to access protected routes. The user state is never saved on the server, instead the server designates specific routes as protected and checks for a valid JWT sent by the user. All of the information the server needs to check is contained within the JWT, meaning less communication is needed with the database. JWT Authentication also means that it is possible to create RESTful API’s with built-in expiration functionality. (Otemuyiwa, 2016)

JWT Based Authentication (Sevilleja, 2015) JWT Based Authentication

Hypertext Transfer Protocol Secure (HTTPS)

Sensitive information, such as credit card information, requires a more secure method of communicating over HTTP. Hypertext Transfer Protocol Secure (HTTPS), is how most sensitive information is transferred across the web. HTTPS uses a trusted third party called a Certificate Authority (CA) to verify the identity of two communicators, and issue them certificates tied to their identity. This is similar to how governments issue ID cards to citizens. They represent a trusted third party that can verify and issue the ID of any citizen.

General Process: CAs issue encrypted certificates that contain identities (including domain name) to servers and clients. A client visits the server using HTTPS and downloads a copy of that certificate as shown in "Certificate Based Mutual Authentication". The client contacts the CA to ask them to verify that the certificate is real. If it is, the CA will respond saying so. Then the client sends the server its own certificate, which the server checks against the CA. If the certificate is verified, then encryption is used to create a secure connection between the server and client.

Certificate Based Mutual Authentication ( “HTTPS Client”, 2010) HTTPS Authentication

Clone this wiki locally