Forem: Mahmoud Abbas

How to Secure the Web: A Comprehensive Guide to Authentication Strategies for Developers

Mahmoud Abbas — Mon, 10 Apr 2023 02:56:42 +0000

Introduction

As the digital world continues to expand, ensuring the security of web applications and protecting user data has become more crucial than ever. One key aspect of web development security is authentication, which involves verifying the identity of users accessing web applications.

With a plethora of authentication strategies available, such as token and session authentication, OAuth, OIDC, and standards like SAML and JWTs, and more, it can be overwhelming for developers to navigate the landscape of options.

In this comprehensive guide, we will delve into various authentication strategies, discussing their strengths and weaknesses, best practices, and practical implementation tips. Whether you're a seasoned developer or just starting out, this guide aims to provide you with a comprehensive overview of authentication strategies to help you secure the web and protect user data effectively.

What is Authentication?

Authentication is the process of verifying the identity of users accessing web applications. This is done by asking users to provide credentials, such as a username and password, to prove that they are who they say they are.
When users provide their credentials, they are typically authenticated by a server, which verifies the credentials and either grants or denies access to the application.

Authentication vs. Authorization

While Authentication makes sure that the users are who they say they are, Authorization determines what they are allowed to do once they are authenticated.

For example, a user may be authenticated as an administrator, but may not be authorized to access certain parts of the application.

Another example is, a user can only have permissions to access and modify their own data, but not other users' data.

Authentication Strategies:

Session-based Authentication

Session-based authentication has been one of the most common authentication strategy used and was the default way of authentication for a long time. It involves the use of cookies to store session information on the client side.

When a user logs in, the server creates a session and stores it in a database. This means that the connection is stateful. The server then sends a session ID to the client in the form of a cookie.

When the user makes a request to the server, that session ID is included in the request, then the server verifies the session ID in the cookie and grants access to the application if the session is valid. If not, the user/client is denied from access and probably redirected to the main/login page.

When the user logs out, the session is destroyed and the cookie is deleted.

Pros:

Easy to implement
Small size
Long lifespan

Cons:

Not scalable, as the server needs to store session information in a database. This means that the server needs to handle a lot of traffic and requests, which can be expensive and time consuming.
Not secure, as the session ID is stored in a cookie, which is prone to XSS and CSRF attacks.

Token-based Authentication

Token-based authentication is very similar to session-based authentication, but instead of storing session information in a database, the server generates a unique JWT token that is sent to the client that and stored in a cookie. This means that the connection is stateless and we don't have the overhead of storing session information in a database.

A JWT token is a string that contains a JSON object that is encoded using Base64. It is signed using a secret key, which is used to verify the token.

When the user makes a request to the server, the token is included in the request in the Authorization header prefixed with the word "Bearer ", then the server verifies the token and grants access to the application if the token is valid. If not, the user/client is denied from access and probably redirected to the main/login page.

When the user logs out, the cookie is destroyed.

Pros:

Scalable, as it's not saved in a database.
Secure, as the token is signed using a secret key, which is used to verify the token.
You can save info about the user in the token, such as the user's role, permissions, etc.

Cons:

Not easy to implement natively, as you need to implement a lot of logic to verify the token and handle errors. but you can use an external library to make it easier.
Shorter lifespan.
Data overhead, as it's generally bigger than a session id and the more data you save in the token, the bigger the token will be.
Is still vulnerable to XSS and CSRF attacks, as the token is stored in a cookie.

What should you do to protect your cookies from XSS and CSRF attacks?

Use the HttpOnly flag, which prevents the cookie from being accessed by JavaScript. This means that the cookie can only be accessed by the server.
Use the Secure flag, which ensures that the cookie is only sent over HTTPS. This means that the cookie can only be accessed by the server over HTTPS.
Set the SameSite flag to Strict, which ensures that the cookie is only sent with requests originating from the same site.
if you are willing to go the extra mile, you can use a refresh token and an access token. which is the way I prefer to do it.

OAuth

OAuth stands for "Open Authorization" which is a standard for authorization, commonly used as a way for users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is provided by companies such as Facebook, Twitter, and Google to permit the users to share information about their accounts with third party applications or websites.

OAuth 1.0 vs. OAuth 2.0

OAuth 1.0 and OAuth 2.0 are two different versions of the OAuth protocol. While both versions serve the same fundamental purpose, they have some differences in their implementation and features.

Here's a brief comparison between OAuth 1.0 and OAuth 2.0:

OAuth 1.0:

Signature-based: uses a signature-based authentication method, where each request from the client includes a signature based on a shared secret and a timestamp. This makes it secure and reliable for authentication.
Token and Secret: uses both a token and a secret to authenticate the client and access protected resources.
Complex Flow: uses a three-legged authentication flow, which involves obtaining a request token, user authorization, and then exchanging the request token for an access token.

OAuth 2.0:

Simpler Flow: uses a simpler two-legged authentication flow, which involves obtaining an access token directly from the authorization server.
Token-based: uses a token-based authentication method, where the client presents an access token in each request to access protected resources.
Multiple Grant Types: supports multiple grant types, including authorization code, implicit, password, and client credentials, providing more flexibility in authentication scenarios.
Scopes: uses scopes to specify the permissions requested by the client, which can be coarse-grained or fine-grained, depending on the implementation.
Widely Adopted: has gained widespread adoption and is widely used by popular web services and APIs for authentication and authorization.

In summary, OAuth 1.0 is a signature-based, complex flow with granular permissions, while OAuth 2.0 is a token-based, simpler flow with support for multiple grant types, flows, and scopes. OAuth 2.0 is more widely adopted, but the choice between OAuth 1.0 and OAuth 2.0 depends on the specific requirements of the application and the level of security and complexity desired.

OAuth 2.0 flow

The most commonly used OAuth 2.0 flow is the Authorization Code Flow. Here's a step-by-step overview of the Authorization Code Flow:

User initiates the authorization process: The user clicks a "Login with (Client Application)" button or takes some other action to initiate the authorization process in the client application.
Client redirects user to authorization server: The client application redirects the user to the authorization server with a request that includes the client ID, redirect URI, and desired scope of access.
User authenticates with the authorization server: The user is prompted to authenticate with the authorization server, providing their credentials (e.g., username and password) to prove their identity.
User grants authorization: After successful authentication, the user is presented with a consent screen where they can review and grant or deny the client's request for access to their protected resources.
Authorization server redirects user back to client: If the user grants authorization, the authorization server redirects the user back to the client application's redirect URI with an authorization code included in the URL.
Client exchanges authorization code for access token: The client application sends a request to the authorization server to exchange the authorization code for an access token. This request includes the authorization code, client ID, client secret, and redirect URI.
Authorization server validates and issues access token: The authorization server validates the authorization code, client ID, client secret, and redirect URI. If they are valid, the authorization server issues an access token and optionally a refresh token to the client.
Client uses access token to access protected resources: The client can then use the received access token to make authorized requests to the protected resources on behalf of the user. The access token serves as proof of authorization.

The Authorization Code Flow is widely used in web applications. However, it also adds additional complexity due to the multiple steps involved, making it more suitable for server-side applications.

OpenID Connect (OIDC)

OpenID Connect is an authentication layer on top of the OAuth 2.0 protocol.

It adds an additional JWT token called an ID token to the Authorization Code Flow. The ID token contains information about the user, such as their name and email address. This information can be used to personalize the user experience and establish an identity for the user.

SAML

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains. It is used by companies to allow their employees to access applications and services from multiple vendors using a single set of credentials. Providing what is known as a single sign-on (SSO) experience for users.

WebAuthn

Web Authentication (WebAuthn) is a new W3C standard for passwordless authentication on the web. It allows users to authenticate to websites using biometric authentication, such as fingerprint or facial recognition, or security keys, such as Yubikeys.

It works by using a public key cryptography system to generate a unique cryptographic key pair for each user.
The private key is stored on the user's device, while the public key is encrypted and stored on the server.

When the user attempts to log in, the server sends a challenge to the user's device, which the user then signs with their private key.
The server then verifies the signature using the public key, and if it's valid, the user is authenticated.

Which one should you use?

For complex applications with multiple users, I would recommend using OIDC. It's more secure and widely adopted.

For web applications only, I would recommend using Token-based authentication with the precautions stated above.

SAML is your best bet if you are building an enterprise application, but sometimes it can be a bit much to handle.

WebAuthn is another great option for web applications, but it's still in its early stages and not widely adopted yet. and it introduces one new challenge - what if the user loses the authenticator.

In my opinion, you can't go wrong with OAuth/OIDC. It's a bit more complex than some other options, especially for smaller applications, but it's secure and widely adopted.

There are other ways to authenticate users, such as 2 factor authentication, One Time passwords, etc. but these are usually used in conjunction with one of the methods mentioned above.

I hope this was helpful. If you have any questions, feel free to contact me.

References

Build a Live Search Bar in React: A Step-by-Step Guide

Mahmoud Abbas — Wed, 29 Mar 2023 21:34:58 +0000

This article provides a tutorial for building a live search bar in React using functional components and hooks. The end result will be a search bar that filters through a list of characters based on user input.

To get started, ensure that you have Node.js installed on your computer and have TypeScript installed as well.
Once you have these prerequisites, you can create your React app using the following command in your terminal:

npx create-react-app live-search --template typescript

Next, create a simple search component using the following code:

  // src/components/Searchbar.tsx
  export default function Searchbar (_props) {
    return (
      <div className="w-full">
        <input type="search" className="w-full">
      </div>
    )
  }

To handle state, you can use the useReducer hook. Create a reducer function that handles different actions and returns a new state based on the action.
The following code shows the reducer function, the initial state, and how to use the hook:

// src/components/Searchbar.tsx

// types
type SearchResult = {
  id: string,
  name: string,
  age: number
}

type State = {
    results: SearchResult[]
    isLoading: boolean
    error?: string,
    query: string
}

type Action =
    | { type: 'request', }
    | {
        type: 'success', results: SearchResult[]
    }
    | { type: 'failure', error: string }
    | { type: 'setQuery', query: string }

// reducer 
function reducer(state: State, action: Action): State {
    switch (action.type) {
        case "request": {
            return { ...state, isLoading: true }
        };

        case "success": {
            return { ...state, isLoading: false, results: action.results }
        };

        case "failure": {
            return { ...state, isLoading: false, error: action.error }
        };

        case "setQuery": {
            return { ...state, query: action.query }
        };

        default: {
            throw Error("Unknown Action")
        }
    }
}

const initialState: State = { isLoading: false, results: [], query: "" }

export default function Searchbar (_props) {
  const [state, dispatch] = useReducer(reducer, initialState)

  // handle input change
  function handleChange (e) {
    dispatch({
      type: "setQuery",
      query: e.target.value
    })
  }

  return (
    <div className="w-full">
      <input onChange={handleChange} value={state.query} type="search" className="w-full">
    </div>
  )
}

Right now, whenever you type something into the searchbar the state changes. That's great!
Now let's add the search logic.

We want to send a request everytime the input changes. so let's create a custom react hook that will handle that for us everytime the input changes.

  // src/components/searchbar.tsx
  // ...old code above
  import { Dispatch, useEffect, useState } from "react"

  const getCharacters = async (query: string): Promise<SearchResult[]> => {
    return await fetch(`API/URL`, {
        body: JSON.stringify({
            keyword: query
        })
    })
        .then(res => res.json())
        .then(data => data.data)
        .catch(err => {
            if (err.message === "DOMException: The user aborted a request.") {
                console.log("request aborted")
            } else {
                throw err
            }
        })
  }

  const useLiveSearch = (dispatch: Dispatch<Action>, query: string) => {
    useEffect(() => {
      // don't send any requests if the input is less than 3 characters
      if (query.length < 3) return
      // set loading state to true
      dispatch({ type: "request" })
      try {
          // this is a helper method that fetches the data for us
          const data = await getCharacters(query)
          if (data) {
              dispatch({ type: "success", results: data })
          }
      } catch (err) {
        // handle errors
          console.error(err)
          dispatch({ "type": "failure", error: "Something went wrong" })
      }
    }, [query])
  }

  export default function Searchbar (_props) {
    const [state, dispatch] = useReducer(reducer, initialState)
    const {query, isLoading, results, error} = state

    useLiveSearch(dispatch, query)

    // handle input change
    function handleChange (e) {
      dispatch({
        type: "setQuery",
        query: e.target.value
      })
    }

    return (
      <div className="w-full">
        <input onChange={handleChange} value={query} type="search" className="w-full">
      </div>
    )
  }

To improve the performance of the app, we need to solve a problem. for examble: whenever a user types a word of four characters, four requests are sent to the server, which is not optimal.
To solve this, we use a technique called debouncing. Debouncing is achieved by delaying the execution of our code, the API requests, and waiting for a bit of time before executing the code if the input changes.
This technique reduces the requests sent to the server and thus improves performance.

Here is the modified code:

  // old code above...
  // modify the api method to accept an abort signal
  const getCharacters = async (query: string, signal): Promise<SearchResult[]> => {
    return await fetch(`API/URL`, {
        signal,
        body: JSON.stringify({
            keyword: query
        })
    })
        .then(res => res.json())
        .then(data => data.data)
        .catch(err => {
            if (err.message === "DOMException: The user aborted a request.") {
                console.log("request aborted")
            } else {
                throw err
            }
        })
  }

  const useLiveSearch = (dispatch: Dispatch<Action>, query: string) => {
    useEffect(() => {
      // add an abort controller to abort requests if the query changes before a request is finished
        const controller = new AbortController();
        (async function () {
            dispatch({ type: "request" })
            try {
                const data = await getCharacters(query, controller.signal)
                if (data) {
                    dispatch({ type: "success", results: data })
                }
            } catch (err) {
                console.error(err)
                dispatch({ "type": "failure", error: "Something went wrong" })
            }
        })()
        return () => controller.abort()
    }, [query])
}

  export default function Searchbar (_props) {
    const [state, dispatch] = useReducer(reducer, initialState)
    const {query, isLoading, results, error} = state

    const [debounceValue, setDebounceValue] = useState<string>('')

    useLiveSearch(dispatch, query)

    function handleChange (e) {
      setDebounceValue(e.target.value)
    }

    useEffect(() => {
      if (debounceValue.length < 3) {
          return
      }
      const timeOut = setTimeout(() => {
          dispatch({ type: "setQuery", query: debounceValue })
      }, 400 ); // you can use any interval you want

      // clean up
      return () => clearTimeout(timeOut)
    }, [debounceValue])

    return (
      <div className="w-full">
        <input onChange={handleChange} value={query} type="search" className="w-full">
      </div>
    )
  }

Great! now our app is more performant.

But let's take it one step further.
To avoid redundant requests, we can use a technique called memoization, which caches the return values of expensive function calls.
In our case, we use memoization to cache API calls.
We can use the lodash memoize method. So let's install it.

npm i lodash.memoize

Here is the final version:

  import { Dispatch, useEffect, useState } from "react"
  import memoize from "lodash.memoize"

  // types
  type SearchResult = {
    id: string,
    name: string,
    age: number
  }

  type State = {
      results: SearchResult[]
      isLoading: boolean
      error?: string,
      query: string
  }

  type Action =
      | { type: 'request', }
      | {
          type: 'success', results: SearchResult[]
      }
      | { type: 'failure', error: string }
      | { type: 'setQuery', query: string }

  // reducer 
  function reducer(state: State, action: Action): State {
      switch (action.type) {
          case "request": {
              return { ...state, isLoading: true }
          };

          case "success": {
              return { ...state, isLoading: false, results: action.results }
          };

          case "failure": {
              return { ...state, isLoading: false, error: action.error }
          };

          case "setQuery": {
              return { ...state, query: action.query }
          };

          default: {
              throw Error("Unknown Action")
          }
      }
  }

  const initialState: State = { isLoading: false, results: [], query: "" }

  const getCharacters = async (query: string, signal): Promise<SearchResult[]> => {
    return await fetch(`API/URL`, {
        signal,
        body: JSON.stringify({
            keyword: query
        })
    })
        .then(res => res.json())
        .then(data => data.data)
        .catch(err => {
            if (err.message === "DOMException: The user aborted a request.") {
                console.log("request aborted")
            } else {
                throw err
            }
        })
  }

  const memoizedGetCharacters = memoize(getCharacters)

  const useLiveSearch = (dispatch: Dispatch<Action>, query: string) => {
    useEffect(() => {
      // create an abort controller to abort requests if the query changes before a request is finished
        const controller = new AbortController();
        (async function () {
            dispatch({ type: "request" })
            try {
                // use the memoized method
                const data = await memoizedGetCharacters(query, controller.signal)
                if (data) {
                    dispatch({ type: "success", results: data })
                }
            } catch (err) {
                console.error(err)
                dispatch({ "type": "failure", error: "Something went wrong" })
            }
        })()
        return () => controller.abort()
    }, [query])
  }

  export default function Searchbar (_props) {
    const [state, dispatch] = useReducer(reducer, initialState)
    const {query, isLoading, results, error} = state

    const [debounceValue, setDebounceValue] = useState<string>('')

    useLiveSearch(dispatch, query)

    function handleChange (e) {
      setDebounceValue(e.target.value)
    }

    useEffect(() => {
      if (debounceValue.length < 3) {
          return
      }
      const timeOut = setTimeout(() => {
          dispatch({ type: "setQuery", query: debounceValue })
      }, 400 ); // you can use any interval you want

      // clean up
      return () => clearTimeout(timeOut)
    }, [debounceValue])

    return (
      <div className="w-full">
        <input onChange={handleChange} value={query} type="search" className="w-full">
      </div>
    )
  }

Wrapping up

In this tutorial, we learned how to build a live search bar in React using functional components and hooks.

We started by creating a simple search component and handling state with the useReducer hook.
We then added search logic by creating a custom hook that sends a request to the server every time the input changes.

Finally, we used the debouncing technique to improve the app's performance by delaying the execution of our code and reducing the number of requests sent to the server.

With these techniques, we can create a fast and responsive search bar that improves the user experience.

That's it. You're all good to go!

Step-by-Step Guide to Creating Your First Web3 dApp with React.js and Wagmi

Mahmoud Abbas — Sun, 05 Mar 2023 09:57:55 +0000

In recent years, there has been a surge of interest in Web3 development, driven by the promise of decentralized technologies and their potential to disrupt various industries.
Decentralized applications (dApps) are a key part of this movement, offering a new paradigm for building applications that are resistant to censorship, tampering, and downtime.
However, developing a dApp can be a daunting task, especially for beginners.

That's where this article comes in - it provides a step-by-step guide for creating your first dApp using two popular Web3 tools: React.js and Wagmi.
By the end of this article, you will have the foundational knowledge to start building your own dApps and contributing to the exciting world of Web3 development.

The first thing we need to do is create our react app.
We will be using typescript for the purpose of this app, but you can use plain js if you want.

To do this just open your terminal in your prefered folder, and type this command.

npx create-react-app web3-dapp --template typescript

Next, we'll open the created folder in our terminal and install the required dependencies.
For this app, we will need just 2: Wagmi and ethers.

ethers is javascript library that allows us to interact easily with Web3 Blockchains.

On the other hand, Wagmi is a library of react hooks that make easier to interact with Blockchains in a reactive way.
It uses the ethers library under the hood. This way, we don't have to deal with ethers first hand.

We can install them by typing this command into the terminal

npm i wagmi ethers@^5

Next up, we will configure our Wagmi client. We're gonna create a separate wrapper component to contain all of the Wagmi client logic.

In our src folder, we are gonna create a typescript file called WagmiWrapper and add the following code:

// src/WagmiWrapper.tsx
import { ReactNode } from 'react'
import { WagmiConfig, createClient, configureChains } from 'wagmi'
import { mainnet, goerli, polygon } from "wagmi/chains"
import { publicProvider } from 'wagmi/providers/public'

// 1- select the chains we want to support 
const supportedChains = [mainnet, goerli, polygon]

// 2- create the configration 
const { provider } = configureChains(
    [...supportedChains],
    [publicProvider()],
)

// 3- create a wagmi client instance 
const client = createClient({
    autoConnect: true,
    provider,
})

type Props = {
    children: ReactNode
}

export default function WagmiWrapper({ children }: Props) {
    return (
        <WagmiConfig client={client}>
            {children}
        </WagmiConfig>
    )
}

Let's go throught this code block by block.

We select the chains that we want to support by importing them from wagmi/chains.
By default, Wagmi supports 50+ EVM compatible chains. here we selected the Ethereum mainnet, Ethereum goerli, and Polygon.
We create the client configration. It takes in 3 arguments:
1. Supported chains (that we selected earlier)
2. List of providers. here we are using the public provider, but we can add more. By default, wagmi offers 3 provider configrations: public, Infura, and Alchemy. or you can create your own custom jsonRpc provider. We will go in details on how to add other providers in a following article.
3. List of websocket providers. (optional)
We create the client instance. It takes in a bunch of arguments that you can check here, but we are only interested in two for the purpose of our applications:
1. autoConnect, which makes the client connect back automatically in the same session if you refresh the website.
2. The provider that we configured earlier.

At this stage, we have successfully created our wagmi client configuration. we just need to incapsulate it in a react component and that's it.

Next, we'll wrap our app with the WagmiWrapper we just created.

We can do that in our App file

// src/app.tsx
import './App.css';
import WagmiWrapper from './WagmiWrapper';

export default function App() {
  return (
    <WagmiWrapper>
      <div className="App">
        // the rest of our app
      </div>
    </WagmiWrapper>
  );
}

Now that we have setup our Wagmi client, we can use the library's hooks to interact with any Blockchains.

Let's create a simple example to demonstrate how we can use the wagmi hooks.

In a separate component, we'll write the logic to connect to a wallet and display it's address or ENS name.

// src/Profile.tsx
import { useAccount, useConnect, useEnsName } from 'wagmi'
import { InjectedConnector } from 'wagmi/connectors/injected'

export default function Profile() {
    const { address, isConnected } = useAccount()
    const { data: ensName } = useEnsName({ address })
    const { connect } = useConnect({
        connector: new InjectedConnector(),
    })

    if (isConnected) return <div>Connected to {ensName ?? address}</div>
    return <button onClick={() => connect()}>Connect Wallet</button>
}

Here we are using 3 hooks from wagmi:

useAccount to check if we are connected and what is the address of the connected wallet.
useEnsName to resolve the wallet's ENS name (if it exists).
useConnect to connect our app to the wallet.

You can check out the library of hooks that wagmi supports from thier offecial website

The last step is to import and use the component we created in the App

import './App.css';
import Profile from './Profile';
import WagmiWrapper from './WagmiWrapper';

export default function App() {
  return (
    <WagmiWrapper>
      <div className="App">
        <Profile />
      </div>
    </WagmiWrapper>
  );
}

In order to test the app, you must have a wallet installed in your browser like MetaMask or CoinBase wallet.

Here is how the final app looks:

Here I'm using a MetaMask wallet. Once I click connect wallet, I'll be prompted to login:

After logging in, the app displays my wallet address:

Wrapping Up

You have now successfully created your first dApp. You can use the other Wagmi hooks to grow your app and add more features to it.
You can find the source code for this project here