REST API

Question 1

what is an API?

Answer 1

it’s an application programming interface and it’s a part of the server that receives a request and sends a response

Question 2

what are the uses of an API?

Answer 2

1- it allows the communication between two applications
2- it controls the access to resources (Security)
3- build on existing functionality

Question 3

what does it mean when a company offers an api to their customers?

Answer 3

it means they have made dedicated urls that return pure response , meaning the response won’t be containing the kind of presentational overhead that you would expect in a graphical user interface like website

Question 4

what is JWT?

Answer 4

is an open standard that defines a compact and self-contained way for securely transmitting information between API’s as a JSON Object and this information can be verified and trusted because it’s digitally signed

A JSON web token, or JWT (“jot”) for short, is a standardized, optionally validated and/or encrypted container format that is used to securely transfer information between two parties.

Question 5

how can u sign a JWT token?

Answer 5

using a secret with HMAC algorithm or public/private key pair using RSA or ECDSA

Question 6

what are some scenarios to use JWT?

Answer 6

Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.

Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn’t been tampered with.

Question 7

What is the JSON Web Token structure?

Answer 7

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

Header
Payload
Signature
Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

Question 8

what is the JWT Header?

Answer 8

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

Question 9

what is the JWT Payload?

Answer 9

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.

Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.

Notice that the claim names are only three characters long as JWT is meant to be compact.

Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.

Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.

he payload is the part of the token where all interesting user data is usually added. Just like the header, the payload is a JSON object. Unlike the header, however, no claims are mandatory. It usually contains application specific claims and the registered claims iss, sub and aud

Question 10

what is the JWT Signature?

Answer 10

To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)

The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

Question 11

How do JSON Web Tokens work?

Answer 11

In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned. Since tokens are credentials, great care must be taken to prevent security issues. In general, you should not keep tokens longer than required.
Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema.

This can be, in certain cases, a stateless authorization mechanism. The server’s protected routes will check for a valid JWT in the Authorization header, and if it’s present, the user will be allowed to access protected resources. If the JWT contains the necessary data, the need to query the database for certain operations may be reduced, though this may not always be the case.

Question 12

Why should we use JSON Web Tokens?

Answer 12

As JSON is less verbose than XML, when it is encoded its size is also smaller, making JWT more compact than SAML. This makes JWT a good choice to be passed in HTML and HTTP environments.

Security-wise, SWT can only be symmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML tokens can use a public/private key pair

JSON parsers are common in most programming languages because they map directly to objects. Conversely, XML doesn’t have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.

Question 13

What is the secret in JWT?

Answer 13

it’s a unique string to the application and used in the signature

Question 14

What is HTTP?

Answer 14

HTTP stands for Hypertext Transfer Protocol, and HTTP is the communication protocol used for browsing the web. This protocol uses a message based model where your client makes an HTTP request to a web server and that server responds with a resource which is displayed in the browser.

Question 15

what does stateless mean?

Answer 15

Stateless means that all requests are separate from each other so every request must contain enough information on their own to fulfill the request. That means that each transaction of message based model of HTTP is processed separately from each other.

Question 16

what are the the HTTP methods?

Answer 16

GET — used to request data from a specified resource where data is not modified it in any way as GET requests do not change the state of resource.
POST — used to send data to a server to create a resource.
PUT — method to update existing resource on a server by using the content in body of the request.
HEAD — this method has the same function as GET method but with a difference that the return of a HEAD method should not contain body in the response. However, the return will contain same headers as if GET was used. HEAD method is used to check if the resource is present prior of making a GET request.
TRACE — method designed for diagnostic purposes. Response will contain in its body the exact content of the request message.
OPTIONS — this method is used to describe the communication options (HTTP methods) that are available for the target resource.
PATCH — The PATCH method is used to apply partial modifications to a resource.
DELETE — The DELETE method deletes the specified resource.

Question 17

What is HTTPS?

Answer 17

Secure version of HTTP protocol is HyperText Transfer Protocol Secure (HTTPS). HTTPS provides encrypted communication between a browser (client) and the website (server).

In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or Secure Sockets Layer (SSL).

Question 18

what is an asymmetric encryption system?

Answer 18

Asymmetric encryption system uses a public key (encryption key) and a private key (decryption keys) to encrypt a message. Anyone can use the public key to encrypt a message. However, private keys are secret, and that means that only the intended receiver can decrypt the message.

Question 19

What is REST API?

Answer 19

REST is acronym for REpresentational State Transfer. It is architectural style for distributed hypermedia systems

Question 20

Who invented REST?

Answer 20

REST was defined by Roy Fielding, a computer scientist. He presented the REST principles in his PhD dissertation in 2000.

Question 21

what is a client in an api?

Answer 21

the client is the person or software who uses the API

Question 22

what is a resource in API?

Answer 22

a resource can be any object the API can provide information about. In Instagram’s API, for example, a resource can be a user, a photo, a hashtag. Each resource has a unique identifier. The identifier can be a name or a number.

Question 23

how does a restful API exposes it’s information?

Answer 23

in the form of information about its resources. It also enables the client to take actions on those resources

Question 24

what does Representational state transfer means?

Answer 24

It means when a RESTful API is called, the server will transfer to the client a representation of the state of the requested resource.

Question 25

What the server does when you, the client, call one of its APIs depends on 2 things that you need to provide to the server?

Answer 25

An identifier for the resource you are interested in. This is the URL for the resource, also known as the endpoint. In fact, URL stands for Uniform Resource Locator.

The operation you want the server to perform on that resource, in the form of an HTTP method, or verb. The common HTTP methods are GET, POST, PUT, and DELETE.

Question 26

In order for an API to be RESTful, it has to adhere to 6 constraints?

Answer 26

Uniform interface
Client — server separation
Stateless
Layered system
Cacheable
Code-on-demand

Question 27

what is the 4 constraints of Uniform interface?

Answer 27

The request to the server has to include a resource identifier

The response the server returns include enough information so the client can modify the resource

Each request to the API contains all the information the server needs to perform the request, and each response the server returns contain all the information the client needs in order to understand the response.

Hypermedia as the engine of application state — this may sound a bit cryptic, so let’s break it down: by application we mean the web application that the server is running. By hypermedia we refer to the hyperlinks, or simply links, that the server can include in the response. The whole sentence means that the server can inform the client , in a response, of the ways to change the state of the web application. If the client asked for a specific user, the server can provide not only the state of that user but also information about how to change the state of the user, for example how to update the user’s name or how to delete the user. It is easy to think about the way it’s done by thinking about a server returning a response in HTML format to a browser (which is the client). The HTML will include tags with links (this is the hypermedia part) to another web page where the user can be updated (for example a link to a ‘profile settings’ page). To put all of this in perspective, most web pages do implement hypermedia as the engine of application state, but the most common web APIs do not adhere to this constraint.

Question 28

what is the result of the uniform interface?

Answer 28

requests from different clients look the same, whether the client is a chrome browser, a linux server, a python script, an android app or anything else

Question 29

Client — server separation?

Answer 29

The client and the server act independently, each on its own, and the interaction between them is only in the form of requests, initiated by the client only, and responses, which the server send to the client only as a reaction to a request. The server just sits there waiting for requests from the client to come. The server doesn’t start sending away information about the state of some resources on its own.

Question 30

stateless?

Answer 30

Stateless means the server does not remember anything about the user who uses the API. It doesn’t remember if the user of the API already sent a GET request for the same resource in the past, it doesn’t remember which resources the user of the API requested before, and so on.
Each individual request contains all the information the server needs to perform the request and return a response, regardless of other requests made by the same API user.

Question 31

Layered system?

Answer 31

Between the client who requests a representation of a resource’s state, and the server who sends the response back, there might be a number of servers in the middle. These servers might provide a security layer, a caching layer, a load-balancing layer, or other functionality. Those layers should not affect the request or the response. The client is agnostic as to how many layers, if any, there are between the client and the actual server responding to the request.

Question 32

cachable?

Answer 32

This means that the data the server sends contain information about whether or not the data is cacheable. If the data is cacheable, it might contain some sort of a version number. The version number is what makes caching possible: since the client knows which version of the data it already has (from a previous response), the client can avoid requesting the same data again and again. The client should also know if the current version of the data is expired, in which case the client will know it should send another request to the server to get the most updated data about the state of a resource.

Question 33

Code-on-demand?

Answer 33

This constraint is optional — an API can be RESTful even without providing code on demand.
The client can request code from the server, and then the response from the server will contain some code, usually in the form of a script, when the response is in HTML format. The client then can execute that code.

Question 34

what Are some important status codes?

Answer 34

1 - 200 OK : The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

2 - 201 CREATED: The request has been fulfilled and resulted in a new resource being created

3 - 204 NO CONTENT: The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

4 - 301 MOVED PERMENANTLY: The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs

5 - 400 BAD REQUEST : The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

6 - 401 UNAUTHORIZED : The request requires user authentication

7 - 403 FORBIDDEN : The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated

8 - 404 NOT FOUND: The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

9 - 500 INTERNAL SERVER ERROR: The server encountered an unexpected condition which prevented it from fulfilling the request.

Question 35

what is the container format in JWT?

Answer 35

JWT defines the structure of the information we’re sending across the network and it comes in two forms — serialized and deserialized. The serialized form is used to transfer data through the network with each request and response. On the other hand, the deserialized form is used to read and write data to the token

Question 36

what does the cryptographic information in the header define?

Answer 36

whether the JWT is signed and/or encrypted, and if so what cryptographic algorithms are used. This information is provided by the alg claim with an algorithm name as a value

Question 37

what is a claim in JWT?

Answer 37

The word claim that I used above comes from the JWT spec and simply means a piece of information asserted about a subject. A claim appears as a name/value pair where the name is always a string and the value can be any JSON value. In the context of a JSON object a claim is simply an object’s key

Question 38

what are the types of claims?

Answer 38

JWTs contain claims that are either registered or user defined. Registered claims are usually part of some standard or a proposal, like JSON Web Token Claims Registry and have specific meanings attached to them. The most common registered claims are: iss that identifies the party that issued the JWT, sub that identifies the party that this JWT carries information about and aud that identifies the intended recipients of this JWT. Often also the other two claims are present: exp that defines the expiration date and iat that defines the time at which the JWT was issued

Question 39

what is an unsecured token in JWT?

Answer 39

some JWTs may also be created without a signature or encryption. This usually happens when a JWT is a part of some already encrypted data structure. Such a token is referred to as unsecured and its header should have the alg claim set to none

Question 40

What are some ways of securing JWT?

Answer 40

JWT are JSON Web Signature (JWS) and JSON Web Encryption (JWE)

Question 41

what is signing in JWT?

Answer 41

The purpose of a signature is to allow one or more parties to establish the authenticity of the JWT. Remember our example of tampering user ID stored in a cookie to get access to someone else’s account? Well, that’s where we can use JWS to sign the token and let verify that the data contained in the JWT has not been tampered with. A signature, however, does not prevent other parties from reading the contents of the JWT. This is what encryption is designed to do. A signed JWT is known as JWS (JSON Web Signature) and in the compact serialized form it carries the signature that appears after the last dot.
The most common signing algorithm for JWTs is HMAC. It combines a certain payload with a secret using a cryptographic hash function (most often, SHA-256) and produces a signature that can be used to verify the message. This is so-called shared-secret signing scheme since both the party that generates the signature and the party that verifies it know the secret. And since both parties know it, both can generate a new signed message.
RSASSA is the other algorithm that is used for signing. Unlike HMAC, it allows the receiving parties to only verify the authenticity of a message, but not generate it. The algorithm is based on the public/private key scheme. The private key can be used to both create a signed message and to verify its authenticity. The public key, in contrast, can only be used to verify the authenticity of a message. This is important in one-to-many signing scenarios, like Single-Sign On, where there’s a only one producer of the message and many consumers. If, for example, a legitimate consumer turns malicious, it is impossible for it to modify a message without the other parties noticing.

Question 42

what is Encryption in JWT?

Answer 42

While signing a JWT provides a means to establish the authenticity of the JWT contents, encryption provides a way to keep the contents of the JWT unreadable to third parties.
An encrypted JWT is known as JWE (JSON Web Encryption) and, unlike JWS, its compact serialization form has 5 elements separated with a dot. Additionally to the encrypted header and payload, it includes the encrypted key, initialization vector and authentication tag.
Similarly to JWS it can use two cryptographic schemes: a shared secret scheme and a public/private-key scheme.
The shared secret scheme is analogous to the signing mechanism where all parties know the secret and can both encrypt and decrypt a token.
The private/public keys scheme, however, works differently. In JWE, all public-key holders can encrypt the data, but only the party holding the private key can decrypt it. What that means is that JWE cannot gurantee the authenticity of the JWT when public/private key scheme is used. To have the guarantee of authenticity both JWS and JWE should be used. Note that this restriction only applies in situations where consumers are different entities from producers. If the producer of the data and the consumer is the same entity, then a shared secret encrypted JWT provides the same guarantees as an encrypted and signed JWT.

Question 43

What is the difference between Authentication and Authorization?

Answer 43

Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is like having a driver license which is given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.

Authorization is an entirely different concept and in simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. Consider the following - You have a working key card that allows you to open only some doors in the work area, but not all of them.