The first and arguably most important part of the Back-End service is the authorization API.
Purpose
The authorization API is built to handle authorizing clients. Clients can be the device or the user of the chrome extension. To the authorization service there really is no difference between the two. The authorization API is there to take in a client name and password. It then returns the client a JWT. The JWT is used to ensure that the client can secure its connection with the product API allowing the product API to remain stateless. In other words each API request can be authorized separately without needing to have a client logged in to the product service.
JWT
JSON Web Tokens. They are are one of two security components in the Product API and are the very purpose of having an authorization API. JSON web tokens are used to securely transmit information encoded as JSON. JWT are signed with a secret and their payload themselves. This is used to generate a unique JWT whose contents must match what they were when the JWT was created. They are useful for allowing a user to use a JWT instead of sending their user credentials every single time. This is the purpose of using the JWT for the product API. JWTs are also able to expire allowing a JWT to be essentially useless even if they can be grabbed.
HTTPS
HTTPS is an end to end encryption schema used on top of HTTP. It is the second component of security in the product api and the main security in the authorization API. By having the sender and receiver agree on a pair of private and public keys information can be sent between such that only the intended destinations can unpack the encrypted payload. This ensures that it is very difficult to see data being sent between clients and servers.
Two Pronged Approach
By combining the usage of JWTs and HTTPS it is nearly impossible to impersonate a user maliciously by a third party. Even if HTTPS is broken unless the malicious party has cracked a message they will not have the users credentials as there is only a JWT for authorization. Since the JWT will expire after a certain period it is very unlikely to have cracked the HTTPS payload in the time period before the JWT expires. So the user is kept safe.
Salting and Hashing
When a user signs up or signs in they are sending a raw password. This should not be persistently kept in storage. Thus in order to keep stored passwords encrypted a salt and hash method it used. Hashing algorithms take an input and produce an encrypted hash. However, this is not usually sufficient. If the user uses a rainbow table to try to guess common passwords using common hashing algorithms they may already have the users passwords to compare against the authorization database. Thus they can get massive amount of user passwords at once. So in order to prevent this a salt is added to the beginning or end of user’s inputs. This is to ensure that the rainbow table attack cannot occur and would take hours to months to years to crack individual user passwords. The salt is kept a secret and is usually very long.
Endpoints
The authorization API has three endpoints.
- signin
- signup
- refresh
signin is where the client will send their clientname and password and recieve a JWT to use with the product api.
signup allows a new client to register and be added to the database. It will return the user a JWT to use right away.
refresh is the endpoint that clients will hit before their JWT expires. However, it will not issue a new JWT if the old one is not close to expiring.