Authentication, Authorization, and API Flashcards
Cryptography
a way to use algorithms and secret keys to keep information secure
It is comprised of techniques for secure communication for adversaries. Adversaries are third-parties who could possibly fake a user’s identity to gain their secret values.
In modern times, cryptography is synonymous with encryption.
Encryption is the process of translating something that’s readable into something that looks like nonsense (i.e. not readable) and being able to translate it from a non-readable state back into something that’s readable.
symmetric encryption
it uses one value to determine how to encrypt data
asymmetric encryption
uses two pieces of information called the public and private keys. The public key is shared with anyone wanting to encrypt a message for the recipient. The private key is used to decrypt the message. Encrypt with public key, decrypt with private key. This is why it’s known as asymmetric, because one key does the encrypting and the other key does the decrypting.
Establishing an HTTPS connection is an example of asymmetric encryption. To break down the steps of encryption between a computer and a Web server that is going to establish a secure HTTP connection (i.e., HTTPS), they would do the following:
The server passes on its public key to encrypt data along with its SSL certificate.
The browser client uses the server’s public key to encrypt a value and generate a new private key.
The client sends the encrypted value and the client’s new private key to the server.
The browser’s private key is used to decrypt messages that have been encrypted with the server’s public key.
The server sends encrypted data to the client using the client’s public key.
The browser decrypts the data from the server and renders the decrypted information.
When is it appropriate to use encryption?
It’s appropriate to use encryption to secure over the wire communication between the client and server (e.g. HTTPS or TLS/SSL). Data at rest (i.e. stored in a database) can also be encrypted. For example, credit card numbers should be encrypted (if they’re stored at all). Sometimes data just needs to be protected at rest and you don’t need the ability to decrypt it. For example, passwords need to be protected at rest, but you don’t need the ability to translate a password back into human readable form. For this reason, hashing is a far more popular way of protecting user passwords.
Hashing
the process of converting a message of any length into a short, fixed-length string. Hashed values cannot be translated back to their original input values. Hashing is deterministic, meaning that every time you hash the same input, you will receive the same output. This is why we use hashing to secure user credentials.
What is a “salt”?
Imagine if multiple users have the same password. This means that they would have the same password digest stored in the database. If one of the users has an exposed password, a hacker could find all the users with the same password digest and hack into all accounts with the exposed password. This is where salting comes into play. The basic idea behind salting is to begin by generating a small, random string or set of bits known as a salt. You would then append the salt to your the user’s password before hashing.
ReST
REpresentational State Transfer
an architecture style for designing networked applications. To be clear, ReST is not an official standard. Instead, it’s a set of rules/constraints.
Decoupled client-server: The client and the server should be decoupled so that they can evolve separately without any dependence on one another.
Stateless: This means that there is no necessary session between the client and the server. Data received from the server can be used by the client independently. This allows you to have short discrete operations. Luckily, this is a natural fit for HTTP operations in which requests are intended to be independent and short-lived.
Uniform interface: RESTful APIs are meant to be self-describing and uniform in their definition. Each operation is intended to be separated by a separate endpoint or URL. In practical real world terms, most RESTful APIs implement the classic CRUD (Create, Read, Update, Delete) operations against a resource that just happens to be in your data model. This uniformity allows developers to easily learn the usage pattern of each API.
In RESTful APIs, you generally have two kinds of URLs, ones that points at collections of resources and ones that point at single resources.
Designing your API
The simplest way to figure out what paths you need in your application is to figure out what resources you need in your application. For many developers, this means looking at the models in your application (and the database tables that power the models).
Cross-Origin Resource Sharing
being able to access resources that are located at an origin different than the origin of the application that’s making the request.
being from the same origin means having the same protocol (http vs https), domain, and port number. In our current example, both the client and the API server are using the same protocol (http) and domain (localhost), but are served on different ports, which is why it’s considered a cross-origin request.
By default, browsers prevent cross-origin requests from happening for security reasons. Although this might make life a little more difficult for developers, restricting this type of requests is a good thing that reduces the number of attack vectors against your applications.
According to the MDN docs on CORS, in order to be considered a “simple” request, it must meet all of the following criteria:
It has to be one of these HTTP methods: GET, HEAD, or POST.
It can only have “CORS-safelisted request-headers”. Essentially this means that if you manually set a header that’s not included on the safelisted request headers list, then the request is no longer a “simple” request.
The Content-Type must be application/x-www-form-urlencoded, multipart/form-data, or text/plain.
OAuth 2.0
Application requests authorization from user- Your app, MyMint.com, asks Johnny for authorization to access Johnny’s financial transactions from chase.com.
User issues Authorization Grant to Application- Johnny authorizes the MyMint.com, and an Authorization Grant is issued to MyMint.com.
Application uses the Authorization Grant- MyMint.com uses the Authorization Grant to request an access token from chase.com’s Authorization Server.
Authorization Server issues access token to Application- chase.com’s Authorization Server checks the authorization grant and issues an access token to MyMint.com. From this point on, MyMint.com will use that access token to communicate with chase.com’s Resource Server.
Access token is used- MyMint.com uses the access token to request Johnny’s financial transactions from chase.com’s Resource Server.
Protected Resources are served- If chase.com’s Resource Server is presented with a valid access token, then it sends back the resources (Johnny’s financial transactions).
JSON Web Token
an internet standard that defines how to create JSON-based access tokens
A JWT is composed of three parts: the header, the payload, and the signature
the first two parts are simply base64 encoded.
The header describes the algorithm that will be used for hashing.
The payload holds identifying information about the user.
Finally, the third part of the JWT is the signature. The signature is the output of hashing the header, the payload, and the secret key, so you’ll need to set up a secret key.
