For this , I'm diving into some best practices for using authentication in your full stack application. Tech Stack in 10 Today's episode focuses on serverless authentication with AWS, as well as some best practices of what to do and what not to do 👨‍💻💭 Here’s a glance at what you’ll learn in this episode: Learnings from coaching 8 people on app development Authentication in AWS primer AppSync and GraphQL API overview DynamoDB and database overview withAuthenticator best practices Experimenting with AmplifyAuthenticator + what not to do! Discussion on multi-user authentication Finalizing the AWS authentication in our app Conclusion 00:00 01:11 01:54 02:16 03:00 05:43 08:38 10:27 11:33 <iframe width="839" height="472" src=" " title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> https://www.youtube.com/embed/LoPB-3gnI6I 👨‍💻 What Is User Authentication in an App Context? When you think about developing an authentication system for your software application, you must ensure your system is highly secure and durable, scalable for a growing user base, and able to keep your resources and authorization requirements in place across the application. User authentication is a process for confirming, and validating, the identity of a user within a system. It is necessary to create a system for account management for your software's users to ensure they must login with valid credentials before using certain (or all) parts of the product or service on the Internet. Online services for authentication might require credentials, such as username and password that are used to identify your account within the pool of valid users. Perhaps you'll want to add in 2FA (Two-Factor-Authentication), an additional security mechanism for authentication to verify the users are who they say they are when they log in. 👨‍💻 How Does Serverless Authentication Work? Serverless authentication is a type of authentication that doesn't require the need for a physical in-house server to store your data. Instead, all of the actions, permissions, and rules are executed in the cloud and users can interact with the features and functionality without any need for a browser plugin. Authentication happens right within the app and gets users the resources and services they have been designated or signed up for. Let's Take a Real Life Example Like the Below Image: Your friend is hosting a birthday celebration and you are invited! 🎂 First of all, on the invite! Birthday parties are so much fun 🎉 congrats So you might gather your resources, such as a birthday present and an appetizer (extra points if there's an accompanying sauce or dip), and drive out to your friend's house. But...when you arrive, you are greeted by this metallic box with some buttons on it. Most remarkably, the door to enter is locked (there are other people's apartments here as well), so there's no way to just go up to your friend's house without a key. Well, were you thinking you could just walk into your friend's house without some sort of verification or authentication? 🤔 That wouldn't be too safe, right? This metallic box will require you to perhaps, ~buzz~ your friend's speaker box (you will have to know the URL you intend to go to, such as ) and then you will need to provide some sort of verification telling your friend who you are and that you are ready to come in (i.e. your username/password, or any such credentials). https://yourwebsite.com/signin Your friend will hear your voice and then go, "ah yes, come on up old friend!", meaning the authentication worked (your verification checks out: you are in fact who you say you are), the door will ~buzz~ (you will be authenticated: the door will unlock), and you'll be allowed to enter (you are now an authorized user: you now have access to your services/resources in the house...err...I mean app). This is authentication in a nutshell, and hopefully gives a real life example of how this can work in an application. Software is very much the same way, and with a service like AWS Cognito user pools, this managed authentication service will let us do this with software and automation, rather than needing to ~buzz~ people in every time into our app. Could you imagine having to buzz people into your app every time? That would be I N S A N E 🙈 Luckily with AWS Cognito, we have a powerhouse of tools to manage our users and these authentication flows! 👨‍💻 What is AWS Cognito? is a service that lets app developers and software engineers authenticate users without having to create their own identity system. AWS Cognito This specific AWS service makes it easy for any developer to get started with authentication because they don't have to build and maintain complex backend code. It provides all the tools and infrastructure needed from the start, such as sign-up and sign-in flows, multi-factor authentication options, integration with social identity providers like Facebook and Google, and more. One of its major benefits is that it can scale incredibly easily for millions of users as your user base grows and your users needs and requirements scale. 👨‍💻 How to Add Authentication to an App Thanks to an AWS framework called Amplify, we can run the following command to add auth right into our app. // begin the authentication process
amplify add auth

? Do you want to use the default authentication and security configuration? `Default configuration`
? How do you want users to be able to sign in? `Email`
? Do you want to configure advanced settings?  `No, I am done.` You can customize the way users sign in between or but make sure that whichever you choose is the one you want to use for the life of your Cognito user pool because you cannot change this specific setting once you build the Cognito User Pool. username email When everything checks out and the scripts run to set up these backend resources for us in the cloud, we'll run the following command to push it to our backend environment: amplify push Alternatively, we can import a Cognito User Pool right into our application in case we have the user pool already set up and just want to import it into our app directly without any configurations. 👨‍💻 Setting Up our GraphQL API In the example in my video, I have created a ToDo application that lists a user's ToDos that they have to do. When I set up my GraphQL API thanks to the AWS Amplify Framework, I provisioned a DynamoDB table for these ToDo types and put an parameter on the type. This means that only the authenticated users who create a ToDo will have access to their own ToDos. More simply, I can't see your ToDos and you can't see my ToDos if we are both authenticated users of this ToDo app. @auth type Todo @model @auth(rules: [{ allow: owner }]) {
  id: ID!
  name: String!
  description: String
} When a user or set of users upload their ToDos, they will show up in the DynamoDB database : like so <a href=" " rel="AWS DynamoDB Key Value Pair Database"> </a> https://www.youtube.com/embed/LoPB-3gnI6I?start=154 👨‍💻 Adding Auth to our React JavaScript Code Now that we've set up our resources in the backend and in the cloud, we now want them to be readily accessible for the users that we will expect to use our application. For this, we will use the HOC (Higher-Order-Component) which will allow us to use this module directly on the script at the end of our file. withAuthenticator export default App App.js import React from "react";
import { withAuthenticator } from "@aws-amplify/ui-react";
import aws_exports from "./aws-exports";
Amplify.configure(aws_exports);

const App = () => {
  return (
    <React.Fragment>
      <div>
        <h1>Code Goes Here!</h1>
      </div>
    </React.Fragment>
  );
};
export default withAuthenticator(App); Now, when we run our code, you won't be able to access anything inside of until we (1.) Have an account; and (2.) Are authenticated in the system. App.js This will look : something like this <a href=" " rel="AWS Amplify withAuthenticator HOC (Higher Order Component)"> </a> https://youtu.be/LoPB-3gnI6I?t=252 We have a nice packaged-up module that has the "Create Account" and "Sign In" modules all neatly coded for us to use in our application thanks to AWS Cognito and AWS Amplify working together. When we log into our account, we are able to see our ToDos! If our login credentials don't check out, we won't be permitted into our app. 🎉 ~ queue the confetti cannon ~ 🎉 👨‍💻 Some Observations In Working with the Module AmplifyAuthenticator Something I noticed when experimenting with this module is that you can customize the entire auth flow with, from the stylings of the Sign-In page to the flow of the user verification when they are creating an account. It's definitely worth checking out the documentation on the website to learn more about what you can do with the module in AWS. Auth One of the modules I was experimenting with was the module and using it as a wrapper around the functional component, like below. AmplifyAuthenticator ⚠️ As a warning, I noticed that using this module in the direct application caused some data to be cached even when you pressed "Log Out". As in, you would need a hard refresh on the page for you to "actually log out" even if you pressed the log out button when switching between users. This can pose a security risk to your users' data in case they do not automatically refresh the page but press sign-out with this module. I am not sure if this was because of being on the same device and logging into multiple users, but it's worth mentioning as I discovered this, which is why I and showed a live version of the data being cached before a hard refresh was done to the page. This module is fantastic for testing the authentication module and fine-tuning it, but always make sure what you put into production checks out in terms of the expected data and access you intend to have. spoke about it here import React from "react";
import {AmplifyAuthenticator} from "@aws-amplify/ui-react";
import aws_exports from "./aws-exports";
Amplify.configure(aws_exports);

const App = () => {
  return (
    <AmplifyAuthenticator>
        <React.Fragment>
        <div>
            <h1>Code Goes Here!</h1>
        </div>
        </React.Fragment>
    </AmplifyAuthenticator>
  );
};
export default App; Based upon this, we'll want to use the or a version of a customized Auth flow for our users to be able to use our application securely and correctly. withAuthenticator 👨‍💻 Wrapping Up Wow we went through a lot! Tech is one of those fast-paced fields where you will constantly find yourself learning and innovating as you go along. There is never only 1 right answer, and I look forward to hearing your feedback and thoughts on what areas of apps, software, and tech you want to learn more about. Check out the full recording below: <iframe width="839" height="472" src=" " title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> https://www.youtube.com/embed/LoPB-3gnI6I Let me know if you found this post helpful! And if you haven't yet, make sure to check out these free resources below: Follow my Instagram for more: @BrianHHough Watch my latest YouTube video for more Listen to my Podcast on and Apple Podcasts Spotify Join my FREE Tech Stack Playbook Facebook Group About the Author: My name is and I am the Chief Technology Officer & Co-Founder of Airblock Technologies, an AWS Community Builder, the Host of the Tech Stack Playbook, and a Five-Time Global Hackathon Winner. I love sharing how tech can change the world and increasing accessibility of programming so others can be a part of this digital wave too. Brian H. Hough This article was also published . here

Flow

Amazon

Apple

Facebook

Google

Instagram

YouTube

AWS re:Invent 2020: AWS Community Builders Program Top Highlights 

📲 Join the Tech Stack Playbook 
(an inclusive community for learning about & discussing technology)

Read My Stories

Too Long; Didn't Read

Auth in a React App with AWS: How Does It Really Work?

Auth in a React App with AWS: How Does It Really Work?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

AWS re:Invent 2020: AWS Community Builders Program Top Highlights

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

AWS re:Invent 2020: AWS Community Builders Program Top Highlights

161 Stories To Learn About Authentication

3 Reasons for B2C Enterprises to Implement Single Sign-on Authentication

4 Dangers of Sticking with Outdated MFA Methods

The Noonification: Tailwindcss? Ill Pass (8/27/2023)

80% Devices in 2023 Are Already Passkey-Ready: Apple, Microsoft, and Google Pushing It Even Higher

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps