Forem: Ammar Raneez

What on earth are graph databases?

Ammar Raneez — Wed, 21 Sep 2022 05:16:13 +0000

You might have heard about SQL and NoSQL databases (they are, after all, the most popular available), but have you heard about a Graph Database? 🤔

Let us look closer into this and explore why you should consider this novel approach.

When we talk about Graphs, we’re talking about very densely connected data with many relationships (Ex: Social network connections and recommendation engines). A graph database is simply a form of the infamous graph data structure almost always questioned during technical interviews.

Graph databases store “nodes” and “relationships” instead of tables and documents.

Imagine sketching ideas on a whiteboard and joining them together forming some kind of mind map. You have the flexibility of thinking about how you would use it. Graph databases have the same influence — that data is stored similar to how your mind map would look like; densely connected relationships, albeit not having a strict predefined model to follow.

Why Graph databases?

Why would we need to use a graph database? After all, almost all applications that we build use either an SQL or NoSQL database.

The most important reason is that it makes the reasoning of data much more understandable — especially when the data is densely connected.

Simply displaying an image that shows why to use a graph database will not suffice, hence, I will compare a simple use case using actual code.

Imagine this scenario this SQL:

Our goal is to find the name of companies that purchased the product “Mac”.

A solution would be as follows:

SELECT distinct c.CompanyName
  FROM customers AS C
  JOIN orders AS o ON (c.CustomerID = o.CustomerID)
  JOIN orderdetails AS od ON (o.OrderID = od.OrderID)
  JOIN products as p ON (od.ProductID = p.ProductID)
  WHERE p.ProductName = ‘Mac’

It obviously is pretty straightforward, however, when we put this exact same scenario into a graph database, things start getting more understandable.

The exact same scenario in a Graph Database design:

The design, in this case, is easier to read and understand since the thought process required to build proper models is not present.

A solution, using Gremlin is as follows:

g.V().hasLabel(‘Product’).has(‘productName’, ‘Mac’)
  .in(‘HAS_PRODUCT’)
  .in(‘HAS_DETAILS’)
  .in(‘PURCHASED’)
  .values(‘CompanyName’).dedup()

Querying, in this case, is much simpler since all you require to do is traverse the graph without having to worry about joins.

Popular Graph Databases

Currently in the industry there are a couple of popular options of graph databases, some of which are:

Neo4j — an ACID-compliant transactional database with native graph storage and processing.
ArangoDB —a scalable, fully managed graph database, document store and search engine in one place.
Amazon Neptune — a fast, reliable, fully managed graph database service

All in all, graph databases can be an excellent solution if you require highly connected data with a large number of relationships — although this topic by itself can be daunting since it requires knowledge of how the graph data structure works.

Keep growing! 😁

Auth0 "Embedded Login" with React

Ammar Raneez — Sat, 02 Apr 2022 05:56:03 +0000

Auth0 is an "Authentication as a Service" provider, which means that it provides an implementation of authentication into your application without you having to implement a full flow yourself. Handling of Id, Access, and Refresh tokens are by Auth0 itself hence, allowing you to focus on the application that you are building and worry less about the storage & access of tokens and security.

In this blog, I will break down how I implemented an authentication flow using Auth0 and React.

You might have come across the "auth0-react" package - a package that is an abstraction of the vanilla "auth0-js" package, which provides a higher-order API that makes the implementation so much simpler at the expense of using an Auth0-provided Authentication page - which handles the registering and log in (you would be redirected to that page). However, it can be customized if you have an account that has billing activated.

I will be using the vanilla "auth0-js" package since I will be using a free account and want the authentication process to happen within my application - an embedded login.

The Setup

There are quite a few steps required in setting things up within the Auth0 dashboard.

Navigate to the Auth0 website and create a new "tenant".
Create a new application in the "Applications" sidebar of the created tenant.
Navigate to the settings tab of the created application.
Add the URLs you will be using in development in the following sections. (Do not forget to update this whenever you use a different localhost, or once you deploy the application).
Enable refresh token rotation (if not enabled) - we will need this to implement the persistence of the user on refresh.
Scroll down to "Advanced Settings" and click on the "Grant Types" tab. Ensure that the "Password" option is checked.
Click on your created Tenant on the top left corner and navigate to "Settings".
Click on the "General" tab and scroll till you find "Default Directory" under "API Authorization Settings".
Add "Username-Password-Authentication" in the default directory. Make sure that there are not any typos.
Navigate to "Rules" on the sidebar and "Create" a new "Empty" rule. This rule will attach a "role" attribute, which we will specify, to the object that we will obtain on authentication. We will use this attribute to implement authorization.
- Add your website name within <your-website>. Make sure you do not edit the namespace other than this. (The rule name can be anything you prefer).
- This rule will run upon a login request, just before the id token is issued, thereby injecting the role into the id token.
Navigate to "Authentication" and create a new database connection, give it the name "Username-Password-Authentication".
One last step. Go back to your created application, copy the Domain, Client ID and Client Secret, and paste those values into a file in your project, in my case, I have pasted them into an env file, along with a few other values that are present in the below screenshot.
- Redirect URL refers to the URL you are running the application on; DB Connection is the database that we created; Response Type states in what form do we want the response on a login; Response Mode specifies where would the response show up - in our case, it would be appended into our URL as a fragment, however, this will not be used since we will be using an Embedded Authentication approach.
Finally, create a new file instantiating "WebAuth" - which comes from the "auth0-js" package as follows. (We need offline_access to obtain refresh tokens)

import auth0 from 'auth0-js';

export const webAuth = new auth0.WebAuth({
  domain: `${process.env.REACT_APP_AUTH0_DOMAIN}`,
  clientID: `${process.env.REACT_APP_AUTH0_CLIENT_ID}`,
  responseType: `${process.env.REACT_APP_AUTH0_RESPONSE_TYPE}`,
  redirectUri: `${process.env.REACT_APP_REDIRECT_URL}`,
  responseMode: `${process.env.REACT_APP_AUTH0_RESPONSE_MODE}`,
  scope: 'openid profile email offline_access'
});

Register

Now that the base setup is in place, we can get into the meat and potatoes. The below code snippet is an example of a signup process.

const loginUser = async () => {
  webAuth.client.login({
    realm: `${process.env.REACT_APP_AUTH0_DB_CONNECTION}`,
    username: email,
    password: password,
  }, async (err, result) => {
      if (err) {
        return err;
      }
      await authenticate(result);
  });
}

const webAuthLogin = async () => {
  webAuth.signup({
    connection: `${process.env.REACT_APP_AUTH0_DB_CONNECTION}`,
    email,
    password,
    user_metadata: {
      role: UserType.CUSTOMER,
    },
  }, async (err, result) => {
    if (err) {
      return err;
    }
    await loginUser();
  });
}

Sign-ups require an email/username and a password. Along with that, you can send additional metadata to enrich a user's profile within user_metadata. If you recall, this attribute is what we referred to to obtain the role attribute.

If the base setup is all good, this request should be successful and you should be able to view this user in the "Users" tab under "User Management".

The obtained result will be an enriched object containing the id and access tokens. The login function called logs the registered user into the application. I will get into that next.

Login

The login flow is relatively straightforward at first glance, as visible in the snippet above. However, it is a slight bit more work to implement the authenticate function that is being called on a successful response.

The following snippet is the authenticate function.

const authenticate = async (result) => {
  auth0Service.handleAuthentication(result);
  await auth0Service.setUserProfile(result.accessToken, result.idToken, dispatch);
}

In the above snippet, an external service is called that does the behind the scenes functionality necessary to persist the user on a page refresh. If persistence is not necessary, this step is not required - the obtained result would suffice.

handleAuthentication is all about storing the tokens in session storage(local storage would work too).

public handleAuthentication(result: any): void {
  if (result.idToken || result.id_token) {
    this.setSession(result);
  } else {
    History.push('/');
    window.location.reload();
  }
}
private setSession(result: any) {
  const expiresAt = result.expiresIn ?   JSON.stringify(result.expiresIn * 1000 + new Date().getTime())
    : JSON.stringify(result.expires_in * 1000 + new Date().getTime());
  this.setSessionStorage(result, expiresAt);
}
private setSessionStorage(result: any, expiresAt: any): void {
  sessionStorage.setItem('refresh_token', result.refreshToken ? result.refreshToken : result.refresh_token);
  sessionStorage.setItem('expires_at', expiresAt);
}

In the above snippet, the result is passed to setSession that obtains the expiry time of the token, to ensure that only a token that is not expired can be used. setSessionStorage stores the obtained refresh token and the expiry time into session storage. (the checks for result.idToken & result.id_token and result.refreshToken & result.refresh_token is sole because there is a possibility that Auth0 returns them as either camelCase or snake_case)

The reason why the refresh token is stored in session storage and not the id or access tokens is to avoid CSRF attacks (since they contain sensitive information). However, the refresh token does not contain any - it is solely used to obtain other access tokens, thereby having no meaning by itself.

setUserProfile is about storing the authenticated user in memory - in this case, redux.

public async setUserProfile(
  accessToken: string,
  idToken: string,
  dispatch: any,
): Promise<any> {
  webAuth.client.userInfo(accessToken, async (err: any, result: any) => {
    if (err) {
      console.error('Something went wrong: ', err.message);
      return;
    }
    return this.authenticateUser(
      accessToken,
      idToken,
      result,
      dispatch,
    );
  });
}

private async authenticateUser(
  accessToken: string,
  idToken: string,
  result: any,
  dispatch: any,
) {
  dispatch(
    login({
      email: result?.email,
      userType: result?.['https://<your-website>/claims/role'],
      idToken,
      accessToken,
    })
  );
}

In the above snippet, the obtained access token is used to get the user information, that was used to sign up. This information then is dispatched to redux. (In the rule, we specified to return the role attribute in our result object. If more information is required, it is as simple as adding that in the same rule 😁).

Persistence On Refresh

Now that we have integrated a portion of persistence within login, this section will focus on restoring the logged-in user on refresh.

// App.jsx
useEffect(() => {
  const dispatchUserData = (authResult) => {
    const { user } = authResult.data;
    dispatch(
      login({
        email: user?.email,
        accessToken: authResult.access_token,
        idToken: authResult.id_token,
        userType: user?.user_metadata?.role,
      })
    );
  }
  const setAuthenticatedUser = async () => {
    let authResult;
    if (isUserAuthenticated) {
      authResult = await auth0Service.getInitialAuthenticatedUser();
    }
    if (authResult) dispatchUserData(authResult);
  }
  setAuthenticatedUser();
}, [auth0Service, dispatch, isUserAuthenticated]);

// External File
public async getInitialAuthenticatedUser(): Promise<any> {
  if (sessionStorage.getItem('refresh_token')) {
    const isUserAuthenticated = this.isAuthenticated();
    const refreshTokenResponse = await this.getUserWithRefreshToken();
    if (isUserAuthenticated && refreshTokenResponse) {
      this.handleAuthentication(refreshTokenResponse);
      const user = await getUser(refreshTokenResponse.access_token);
      return { ...user, ...refreshTokenResponse };
    }
  }
}

public isAuthenticated(): boolean {
  const date = sessionStorage.getItem('expires_at');
  const refreshToken = sessionStorage.getItem('refresh_token');
  if (date && refreshToken) {
    const expiresAt = JSON.parse(date);
    if (!refreshToken || (new Date().getTime() > expiresAt)) {
      this.removeSessionStorage();
      return false;
    };
    return true;
  }
  return false;
}

private async getUserWithRefreshToken(): Promise<any> {
  const response = await axios.post(`https://${process.env.REACT_APP_AUTH0_DOMAIN}/oauth/token`,
    {
      grant_type: 'refresh_token',
      client_id: `${process.env.REACT_APP_AUTH0_CLIENT_ID}`,
      refresh_token: sessionStorage.getItem('refresh_token'),
      client_secret: `${process.env.REACT_APP_AUTH0_CLIENT_SECRET}`
    },
    { headers: { 'Content-Type': 'application/json', }, },
  );
  return response.data;
}

private async getUser(accessToken: string): Promise<any> {
  webAuth.client.userInfo(accessToken, async (err: any, result: any) => {
    if (err) {
      console.error('Something went wrong: ', err.message);
      return;
    }
    return result;
  });
}
public removeSessionStorage(): void {
  sessionStorage.removeItem('refresh_token');
  sessionStorage.removeItem('expires_at');
}

The snippet above is placed in the App file because it runs on page load. The useEffect defined calls a helper function to obtain the current logged in user and stores them in redux.

getInitialAuthenticatedUser calls a function that checks if the user is authenticated. This function, isUserAuthenticated verifies that the token stored in session storage is not expired (it removes it if so and returns false - that there is no user).

The getUserWithRefreshToken function speaks for itself. It calls an API of your created Auth0 application passing the refresh token available in session storage to obtain a response. The same procedure is followed where the newly obtained refresh token is stored in session storage overriding the currently existing one.

getUser is called with the obtained access token that will finally return the user object.

Congratulations! You now have a working Authentication flow implemented using Auth0 😁

Keep Growing!

Understanding JWT

Ammar Raneez — Thu, 17 Mar 2022 15:06:37 +0000

One of many ways of implementing Authentication & Authorization into your applications is the JWT (JSON Web Token)

A JWT is a string of random characters that is an encoded form of information.

Its a methodology of transmitting information between two parties securely in JSON format. The information can be trusted since it is digitally signed using a secret/key not disclosed to the user. In other words, only the party that has signed it has access to the secret/key, hence maintaining integrity.

Examples of where JWT is used

Authentication | Authorization
Transferring of sensitive data between parties (as mentioned above)

Perhaps the most common usage of JWT is for scenarios of Authentication. The procedure followed is as follows:

Once a user logs in, a JWT is issued to the user from the server.
The user sends this token with each subsequent request to the server via the Authorization header.
The server verifies this token to ensure that the user is who they claim to be and sends back the requested route/service if it was verified.

Note Although the JWT is signed and protected from fraud, this does not mean that it is encrypted - it is base64 encoded, which means that you could use a base64 decoder to get the JSON information. Therefore, avoid storing secret information in the JWT unless that information is by itself encrypted.

JWT Structure

The JWT consists of 3 main components, each separated by a single dot (.)

Header
Payload
Signature

A JWT would therefore be in the form of:
hhhhhh.pppppppp.ssssss

Where the "h" characters represent the header, the "p" characters the payload, and the "s" characters the signature.

Let us shed some light on what each of these components represents.

The Header

The header usually gives information about the token itself: the type (in this case, JWT) and the algorithm used to sign it (Ex: SHA256).

An example Header is as follows:

  {
    "alg": "HS256",
    "typ": "JWT"
  }

The Payload

Perhaps the most important part of the JWT. This is where the "Claims" (user information and any additional data) are stored. "Additional data" could be the iat (issued at), sub (subject) and aud (audience).

An example Payload is as follows:

  {
    "sub": "1234567890",
    "iat": 1516239022,
    "name": "John Doe"
  }

The Payload and Header are Base64Url encoded.

Fun fact for the curious minds: Authorization can be implemented by having a "role" attribute in your JWT. For example:

  {
    "sub": "1234567890",
    "iat": 1516239022,
    "name": "John Doe",
    "role": "Admin"
  }

This "role" attribute can be validated in the backend to provide certain permissions for the calling user. For example, the server could check if the token has an Admin role, and if so, let the user access that specific resource.

The Signature

The Signature is a signed combination of the Base64Url encoded Payload & Header, the algorithm defined in the Header and a specified secret.

For example, say we are using the SHA256 Algorithm, then the secret would be as follows:

  HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    your-256-bit-secret
  )

The signature is to make sure that the data has not been altered. Also, to verify whether the user is who they claim to be - in cases where a private key was used for the signing process.

A Final Example

jwt.io

All in all, JWT can be intimidating if all we do is read about it and not apply it anywhere. However, once you implement Authentication using JWT, you will fully understand the entire concept - it might even become second nature.

Keep growing!

Authentication — the bare minimum

Ammar Raneez — Sat, 12 Mar 2022 14:51:19 +0000

Authentication can be a complex topic, mainly because of the sheer number of various solutions and methods available. In this blog, I will discuss two popular ones and later blogs dive deeper into each and others.

Authentication is about verifying the identity of a user. For instance, when you login into an application using email/username & password, you are being authenticated to make sure that you are who you claim to be.

Is it Authentication Or Authorization?

A confusion currently in the tech community is on this topic. People use these terms interchangeably; some even say that there is no difference whatsoever.

Authentication & Authorization are not the same — I would even say that they are not even similar.

Authorization is all about access rights, or in simple terms, what permissions you have.

Let us look at an example (this may/may not be the actual procedure followed):

User A, a customer, logs into Amazon to purchase products. User B, an admin, logs into Amazon to remove products that have no more stock.

In the above example, User A can only purchase products; they cannot remove, while User B can purchase and remove them. This is the difference between Authentication and Authorization. Although User A has logged in and can purchase, they cannot remove them, this functionality is only allowed to be performed by an admin. In other words, User A has permission to only buy; User B has permission to buy and remove.

Types of Authentication

There are a couple of different ways that you could implement authentication into your applications — here are two of the more popular ones:

JSON Web Tokens (JWTs)
Sessions

JWT is a way of authenticating users and sharing information between two parties, particularly a client and a server. It’s a string of random characters that is an encoded form of user details. The client sends this token with each request to the server — where it verifies whether or not the provided token is valid.

The user sends a login request to the server
The server authenticates the login and sends a token to the user
The user sends a new request with the provided token
The server checks whether the token is valid or not and sends the requested pages to the user if it was valid

Sessions are also a way of authenticating users and sharing information between client and server. It is a container of user information generated and saved on the server. This session is sent to the user via a cookie, which is used to send new requests where the server verifies.

The user sends a login request to the server
The server authenticates the login and sends a cookie containing the generated session ID
The user sends a new request with the provided cookie
The server checks for the ID found in the cookie. If the ID is found, it sends the requested pages to the user

There are other methods as well, such as OAuth (Ex: Google, Facebook logins) and Authentication as a Service (Ex: Auth0, Cognito).

All in all, it can be a complex topic, but it does not have to be if learnt well. Keep growing!