A) iOS (back to top...) "iOS" is Mac's operating system. You can click here to read more about the "i" that's so popular with Mac's branding format. B) Healthkit (back to top...) "Healthkit" is an app made by Mac that gathers all of your health related information that's being collected by your iWatch or your iPhone. From the standpoint of AHA, you used to be able to access an individual's FitBit directly. Now, with Apple, you have to interface with "Healthkit" in order to access that information. We're going to do that with an application built in Node... A) oauth (back to top...) OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the Internet. OAuth, which is pronounced "oh-auth," allows an end user's account information to be used by third-party services, such as Facebook, without exposing the user's password. OAuth acts as an intermediary on behalf of the end user, providing the service with an access token that authorizes specific account information to be shared. The process for obtaining the token is called a flow. B) Open API (back to top...) An API is an Application Programming Interface that allows two applications to talk to one another. The user doesn't see it. One page is sending requests to a database and the API facilitates the response to those requests without the page the user is on to every change or be refreshed. An Open API is one that is available to the public. Generally an API is going to be something that's restricted to a particular company and you need to be validated in order to interact with it. An Open API is going to be available to the general public. C) Markdown (back to top...) "Markdown" is a lightweight markup language with plain text formatting syntax. Its design allows it to be converted to many output formats, but the original tool by the same name only supports HTML. Markdown is often used to format readme files, for writing messages in online discussion forums, and to create rich text using a plain text editor. D) Single Source of Truth (back to top...) The values coming from your page are generally coming from your DOM (Document Object Model). In other words, from your form fields. It is possible, though, that a value can be stored in JavaScript and in that instance you've got two "sources of truth." The "Single Source of Truth" is the data that's coming from the user, usually in the context of a field they've manually entered data in, as opposed to a potentially conflicting piece of data coming from JavaScript or something similar. E) State (back to top...) In more "normal" programming languages, the "state" of the program is all its global variables, static variables, objects allocated on the heap, objects allocated on the stack, registers, open file descriptors and file offsets, open network sockets and associated kernel buffers, and so forth (stackoverflow). For the sake of our API, the "state," then, is going to be the position our user / page is in that's poised to deliver data. F) Microservices (back to top...) A Microservice is like a piece of a puzzle, only it does something all by itself. Here's the definition from Wikepedia: Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[2] It also allows the architecture of an individual service to emerge through continuous refactoring.[3] Microservice-based architectures enable continuous delivery and deployment. It's a piece of a greater whole. G) Containerization (back to top...) Containerization is similiar to Microservices, but they're not tied to any one computer or any application. Click here to read more about the differences. H) IDE (back to top...) IDE means "Integrated Development Environment." I) API Modeling (back to top...) API Modeling is a process where you're breaking down what your API needs to accomplish. Here's the definition from the "Haufegroup..." API modeling consists of 5 activities that help identify the requirements of your API design: 1) Identify the participants, or actors, that will interact with your API 2) Identify the activities that participants wish to achieve 3) Separate the activities into steps that the participants will perform 4) Create a list of API methods from the steps, grouped into common resource groups 5) Validate the API by using scenarios to test the completeness of the API The goal of each step is to explore the requirements of the API from a variety of different perspectives: those involved (the participants), what they want to do (the activities), and how they will complete an activity (the steps). The modeling process will be iterative, so it should be expected that each modeling activity may require that you revisit the previous step as previously hidden details are exposed. J) enum (back to top...) "enum" is short for "enumerate" and it is used to restrict a value to a fixed set of values. It must be an array with at least one element, where each element is unique. The following is an example for validating street light colors: K) artifact (back to top...) "Artifact" is just a fancy word for "documentation." Click here for more info. L) OAS (back to top...) OAS stands for "Open API Specification." It's referring to the standard used to create your "artifact." M) CRUD (back to top...) Acrostic that means "Create Read Update & Delete." The four main functions of a database. N) contract (back to top...) An API contract is a document that is an agreement between different teams for how the API is designed. The most common form of an API contract today is an OpenAPI Specification (formerly known as Swagger). OAS is an vender neutral, portable, and open API description format, which standardizes how REST APIs are described. The question of “who should create it” can be a tricky one. I work at Stoplight, where I help lots of people build out an OAS file, so I see a lot of different ways. Best practice is that it is either built by committee (i.e. architectural council, group of reviewers) or by an API or software architect. It really depends on the organization. In many cases where the team is smaller, it is just a couple of developers agreeing on different aspects of the API design. The most important thing is that everyone agrees that what is in the specification or contract is the agreed upon design of the API (from quora). O) ETL (back to top...) From webopedia: ETL is short for extract, transform, load, three database functions that are combined into one tool to pull data out of one database and place it into another database. Extract is the process of reading data from a database. In this stage, the data is collected, often from multiple and different types of sources. Transform is the process of converting the extracted data from its previous form into the form it needs to be in so that it can be placed into another database. Transformation occurs by using rules or lookup tables or by combining the data with other data. Load is the process of writing the data into the target database. P) Datapoint (back to top...) A data point is a discrete unit of information. In a general sense, any single fact is a data point. In a statistical or analytical context, a data point is usually derived from a measurement or research and can be represented numerically and/or graphically. The term data point is roughly equivalent to datum, the singular form of data. (whatis.com). Q) Boilerplate (back to top...) Boilerplate is the term used to describe sections of code that can be included in many places with little or no alteration. It is more often used when referring to languages which are considered verbose, i.e. the programmer must write a lot of code to do minimal jobs. Boilerplate code is a piece of code which can be used over and over again or we can say it, a piece of reusable code. (medium.com). Once you have everything downloaded, you're going to need to run and install "Yarn." It's a little confusing at first because it would appear as though it was something that came with the Boilerplate package. But if you go with just that, you'll get an error that the "yarn" is an unrecognized command. You have to install Yarn on your machine and you can do that by heading out to https://yarnpkg.com/lang/en/docs/install/#windows-stable. bash bin/development.sh R) Endpoint (back to top...) ...today endpoint is used most commonly in network security and end user mobility circles to mean any device outside the corporate firewall. That could be a laptop, tablet, or mobile phone on the “edge” (or periphery) of the network and which individuals connect to the central network (from Druva). S) YAML (back to top...) YAML is the format you'll use to document your OpenAPI. It stands for "YAML ain't markup language." A) Definition / Description (back to top...) The best way to describe an API is to envision a page that would list a bunch of things, but without the GUI. So you have the info, but no HTML or CSS. Think of it this way: In the past, if you wanted to list all of the employees in an organization, you would have a page that had some backend code on it that would make a call to the database via a query that would grab all of the names from a database. Then with the appropriate HTML and CSS you would create the necessary scaffolding to display the results coming from the database. An API takes a different approach in that it's not at all concerned about the visual aspect of that list of employees. Rather, it focuses exclusively on the data and instead of being something that is limited to a specific URL, it's set up to be triggered by a RESTful dynamic so it can be accessed potentially by multiple domains. B) Open API Specification (back to top...) An API is distinct from Spotlight and things like Swagger etc. The API is the code, Spotlight is your artifact and testing facility. You're using these tools to spec your API in a way that both users and developers can understand and implement into their own system. A) Definition / Description (back to top...) First thing: OAS, Stoplight and Swagger are tools and testing enviornments that are code agnostic. You'll write you code later, the one caveat being that you'll be sending and receiving your data in the context of JSON. This is a tool used to generated API documentation based on OAS 3.0 specifications. "OAS" stands for "Open API Specification." We've said that more than once, but it bears repeating...! If you're inclined to think that an artifact or a contract may not be needful, consider the graphic below: You can see why you want to pause for a moment and engage the Stoplight dynamic and spec out your API according to the contract that exists between you, your GUI crew and your end user. B) Resources (back to top...) Here are some useful Stoplight tutorials and docs:

• webinar
• walkthrough
• design guide

A) Definition / Description (back to top...) Swagger is a resource all by itself, but it's also often used to refer to OAS version 2. That can make things confusing, but if you can keep those two things in mind, you'll be able to successfully navigate most of the conversations that mention Swagger in either of those two scenarios. B) What's the Difference Between Swagger and Stoplight (back to top...) What's the difference between Swagger and Stoplight? This is coming from stackshare... StopLight vs Swagger UI: What are the differences? StopLight: Visual API Tooling. Stop writing thousands of lines of specification code. Our intuitive visual editors significantly cut down on design time, and are spec agnostic. Generate OAI (Swagger) and RAML specification code on demand; Swagger UI: dependency-free collection of HTML, Javascript, and CSS assets that dynamically generate beautiful documentation. Swagger UI is a dependency-free collection of HTML, Javascript, and CSS assets that dynamically generate beautiful documentation and sandbox from a Swagger-compliant API. Bottom line: With Swagger, you're getting a service that aids in actually generating documentation. Spotlight doesn't do that. C) Swagger Petstore Example (back to top...) Swagger Petstore is a sample of a fully armed and operational Open SPI contract that you can you run and play with to get your feet wet. For every end point, there's a corresponding "Try it Out" button. To see the interface that allows you edit that sample - which is a great way to begin with a solid and accurate starting point - head out to the editor which you can access by clicking here. 1) CURL (back to top...) Curl transfers information to data to URLs. You can use Postman, but you can also use CURL which stands for "Client URL." The bottom line is that when POST, GET, DELETE or UPDATE are utilized, you're sending info to a URL which will respond according to the database that's positioned behind that URL. When you're testing your Open API's, you're not necessarily using a database. To mimic that scenario, you'll use something like Postman or...Curl. Here's a video that you can watch that gives you a two minute intro to Curl. When you click on the "Try it Out" button, you'll see the CURL request, the Request URL and the Server Response. D) Create and Edit Your Open API on Swagger (back to top...) To create / edit your Open API on Swagger, you're going to go out to http://editor.swagger.io/A couple of terms right out of the chute:

• Resource - a collection of endpoints in one category. For example, "users" is a resource. "Comments" is a resource. And in the Comments resource, you've got several "endpoints."
• endpoints would be something like "delete," "edit" and "insert." Those endpoints correspond to a specific resource.
• Model is the schema of your database, more or less

1) Petstore Example (back to top...) Here's the original "Petstore" example: ① "schemes" is referring to either "http" or "https." If you're using both, rather than separating those two values with a "," you're going to use a "-" character. ② your "basePath" is the path upon which all of your others are built. ③ The "path" that's being asked for is the path you're constructing in your project. You see that in the screenshot to the right. You'll also specify whether it's a "GET" or "POST." This is also technically categorized as an "endpoint." ④ The "tag" is an intuitive label you're using to arrange your various endpoints. The highlighted section represents a list of all your tags in your contract. You'll see each tag reiterated along with more detailed information after each path / endpoint. ⑤ Operation ID is an optional unique string used to identify an operation. If provided, these IDs must be unique among all operations described in your API. An "operation" is anything that falls under the heading of something like GET, PUT, POST, etc. ⑥ if your endpoint is going to "consume" some data (like in the "authentication" api we're building where it's going to be looking for a JWT in the HEAD), this is where you would document that. Otherwise, it's superflous. ⑦ similar to "consume," only this time it's what your API is "producing." In the example used in the tutorial, the output is JSON. ⑧ if you're getting ready to edit a resource, chances are excellent you're going to be looking at a URL that has the ID of that particular entity. This is where you would document what your app is expecting. In this example, there is not "GET," so we're set. This section would be deleted. ⑨ "responses" is pretty much a default setting in this instance. This is from the website: ⑩ here's where you're going to specify your security dynamic ① "put" doesn't exist in this app, so you can delete all of this stuff! Remember, "put" is your operation. Next you'll have your "tag." At this point, you're still on "pet..." ② you're now on a new "path," hence the different indentation and look. This is going to be the route in your application and then what follows is repeat of what you've just done! ③ here's your Security Definitions which are defined here: https://swagger.io/docs/specification/2-0/authentication/. Basically, it's the section where you're defining all of the security dynamics you've got on your app. ④ arbitrary name you give to this particular authentication piece ⑤ scopes refers to the "scope" of the authenticated user's permissions ⑥ An API Key is... For your purposes you will be using a JWT which will be documented as basicAuth. ⑦ definitions is where you're outlining the basic schema of the relevant tables in your database. Click here to see of the types. 2) The Swagger v3 Contract (back to top...) You're working with version three of Swagger. The final working Open API contract looks like this: The Basic Structure and the syntax you need for the sake of Authentication is located here. You can find all kinds of real world examples by going out to https://unpkg.com/browse/openapi-directory@1.1.3/api/. A) Apicurio (back to top...) Login by clicking on the link. Enter in your basic info and then begin with the "Design" section. Everything is pretty self-explanatory. Know that "tags" is an object that allows you to group the "paths" (endpoints) into named groups in the Swagger UI display. You don't need that for this challenge. Server Variables: You're just establishing some protocols here. Click here for more information and examples. B) Working Example (back to top...) Here's a working example of the Authentication OpenApi that I had to craft using Apicurio... There was an already exising sample of an authentication OpenAPI on Stoplight. Here's what that looked like: A) json_decode (back to top...) In this case, you're getting some JSON and you "decoding" it into a PHP array. It looks like this: ...and you get this: Array ( [0] => Array ( [name] => Jonathan Suh [gender] => male ) [1] => Array ( [name] => William Philbin [gender] => male ) [2] => Array ( [name] => Allison McKinnery [gender] => female ) ) If you wanted to loop through it, you would do this: ...and it would look like this: Jonathan Suh, male
William Philbin, male
Allison McKinnery, female
B) json_decode (back to top...) To convert a PHP array into a JSON string, you would do this: ...and you get this: [{"name":"Jonathan Suh","gender":"male"},{"name":"William Philbin","gender":"male"},{"name":"Allison McKinnery","gender":"female"}] For more info, click here. You can head out to https://www.w3schools.com/js/js_json_php.asp for other examples as well. As has been mentioned before, a Boilerplate is a piece of re-useable code... What you're looking at here is a boilerplate application for building RESTful APIs Microservice in Node.js using express and mongoose in ES6 with code coverage and JsonWebToken Authentication. A) Terms and Technologies (back to top...) Here are some terms and technologies... 1) Next Gen JavaScript - it's the same thing as ES6. ES6 is the newest verison of JavaScript and it offers some neat enhancements and shortcuts. You can read more about how functions can now be written using the "fat arrow (=>)" by clicking here as well as some other information about "let" and "const" and some other things by clicking here. 2) Babel - Babel is a compiler that "dumbs down" whatever ES6 code you've written to "old school" JavaScript so that you code can run on older servers. 3) Gulp - Gulp is a tool that you use in the context of Node that simplifes and streamlines some of your workflow. B) JSON WebToken Authentication (back to top...) For the app you're building, you're not trying to access HealthKit, rather HealtKit is trying to access your database. You're not knocking on their door. Rather, they're knocking on yours. The login credentials are going to be kept in a separate database on our server. The whole purpose of their having reached out to AHA is to facilitate an ETL transaction. They're going to be coming to you with a JSON WebToken. Your job is to authenticate them based on that token and then give them clearance to proceed to the other parts of our system. So, what is a JSON WebToken? This is all coming from "bits and pieces"... A JSON Web Token (JWT) is a safe, compact, and self-contained way of transmitting information between multiple parties in the form of a JSON object. The way that it typically works is that a user wants to login to an app and clicks on the option to login using Facebook. The app knocks on the door of Facebook with the user's Facebook credentials (if the user is logged in to Facebook already) and Facebook responds with at JWT that has all of the user's info and that user is admitted into the app. The structure of the JWT is divided up into three parts:

• header
• payload
• signature

The header typically consists of two parts: the token's type, and the hashing algorithm that is being used. The payload is where the actual information that we want to send is stored. Here is an example of a simple payload. Know that payloads can be way more complicated than this to ensure better security. The signature is used to verify that the message was not altered before reaching its destination. This is usually done by using private keys. These three parts are usually encoded into three Base64-URI strings that are separated by a . in between them. Here's what a real life JWT (pronounced "jot") looks like: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiJ1c2Vycy9Uek1Vb2NNRjRwIiwibmFtZSI6IlJvYmVydCBUb2tlbiBNYW4iLCJzY29wZSI6InNlbGYgZ3JvdXBzL2FkbWlucyIsImV4cCI6IjEzMDA4MTkzODAifQ. 1pVOLQduFWW3muii1LExVBt2TK1-MdRI4QjhKryaDwc Yes, everything is encrypted, but not always. You've basically got two different types:

• JavaScript Web Signature - comes with a signature to prove it's authenticity but the contents are not encrypted.
• JWE-JS - comes with a signature and the contents are encrypted.

To easily decode, verify, generate, or just play around with JWTs, check out the JWT.IO Debugger by Auth0. A) Definition (back to top...) Dockerizing" is the facility that allows an engineer to package up an entire application and make it portable and capable of being inserted into any application / environment. Click on the link to get a run down on how to get things set up. To set up an account, click here. What makes this so crucial to our Healthkit project is that we're going to package our authentication code within the Boilerplate and then stick that into a Docker environment. A couple of key concepts: You're going to write your code to what amounts to a "Docker Image." That "image" file is run by the "Docker" facility on your server. Everything is self contained so you don't have to concern yourself with different technologies installed on your server. If you have "Docker," you're all set! A couple of changes that had to be made in order to get this to work: First of all, I needed to change the "experimental" setting to "true" in Windows 10 settings. To do that, right click on the Docker instance, go to Settings -> Daemon -> Advanced -> set "experimental" to "true." Second, I had to enable nested virtualization by going to the "Parallels" icon in the upper right hand corner of the screen and click on "Control Center." From there, click on the "gear" icon and then "CPU and Memory." You'll see the box to click on at that point. A) Stoplight (back to top...) 1) Nomenclature (back to top...) After you login to Stoplight, click on the the "Applied Health Analytics" name under "Organizations" and click on "Healthkit Integration." After that click on, "Authentication Service.oas3." Here's what you've got in place right now as far as "basics:" a) Request Parameters (back to top...) You've got two query parameters: username and password b) Responses (back to top...) The route is "authorization" 200 -> jwt string which is going to be an array. This is what happens in the event of a successful response from the server. In other words, the authorization was successful. This theoretical in that you're probable not using a GET, but this is a starting point nevertheless. default -> this is your error code. c) Send a Test Request (back to top...) i) Settings (back to top...) A couple of things: First, you'll notice on the "Settings" tab there's a snippet about "$$.env" variables. Refer to the call box to the right for info about that. CORS is something you'll need in place to protect any personal information in the context of your testing. ii) Query (back to top...) Here you're documenting your query parameters. iii) Code Generation (back to top...) This is what you get after sending a "Test Request." A lot of this, I think, are placeholders right now, as far as what's on Spotlight right now. But the thing you want to be sensitive to is the "Headers" section. "Headers" is going to be the place where you define the content type. You're not going to be rendering a page. Rather, you're going to be making available some JSON - at least I think that's the target. A) Overview (back to top...) "OAuth" means "Open Authentication..." OAuth, which is pronounced "oh-auth," allows an end user's account information to be used by third-party services, such as Facebook, without exposing the user's password. OAuth acts as an intermediary on behalf of the end user, providing the service with an access token that authorizes specific account information to be shared. The process for obtaining the token is called a flow. The bottom line is that you're not exposing the user's password. When you login into APIcurio using your Github account, you're not using your username and password from Github to login. Rather, a pre-manufactured agreement has been established by both Github and APIcurio which includes a specific URL. Click here to watch a video that details that process. Imagine "MyBucksApplication" provides great dashboard views of financial information. Sarah wants to view her "Memorial Bank" statements via the "MyBucksApplication." She logs into "MyBucks" and "MyBucks" reaches out to "Memorial Bank." "Memorial Bank" receives an Authorization Request, answers it in the affirmative and then "MyBucks" responds with an Authorization Grant, "Memorial" gives "MyBucks" an Access Token. That Token gives "MyBucks" access to specified areas of "Memorial Bank" that are particular to Sarah. Notice there's no exchange of Sarah's login credentials that are particular to "Memorial Bank." That's the beauty and the utility of OAuth. Click here to watch a video that gives you an Overview of OAuth. A) Working OpenAPI Contract (back to top...) 1) Swagger Version (back to top...) When you go out to Swagger's Editor, you're given the "Petstore" example which represents a sound starting point right out of the chute and it's here where you can begin writing your contract. Here's the Authentication code that passed the Swagger error check: After you've finished Editing, you can save it to your "SwaggerHub" account. 2) Stoplight JSON Version (back to top...) When you import your code from Swagger to Spotlight, you want to be sensitive to the fact that Stoplight expects JSON code and it's a little more "picky" when it comes to certain elements of your code. In this case, it was the "tags" portion of the "tags" element which is lighlighted below: B) JWT / Node Tutorial (back to top...) This is a based on a video tutorial that runs through JWT authorization on Node: ① import express ② "jsonwebtoken" is used to return the JsonWebToken as a string. ③ initialize the "app" variable with express ④ just a basic route / index page ⑤ this is the route we want to protect. The "protective" dynamic is where you see verifyToken ⑥ this is how we're getting our JSONWebToken ⑦ usually it's here where we would retrieve our user from the database. For this example, we're creating a user on the fly. Again, this is what would normally be coming from the database or, for the sake of this instance, this is what's going to be coming to us - a fully validated user that will have all of the info within it's payload. ⑧ here's where you're creating your token and your payload etc. This goes back to the documentation that you see at https://www.npmjs.com/package/jsonwebtoken. There it's documented as both synconous and asyncronous. This is synronous so we're using a callback. This particular line is utilizing ES6. Again, this is producing the token. ⑨ this is where you're breaking your token down into its payload etc. This is middleware in that you're accessing the request and the response objects as well as what represents the "next" middleware function in the application's request-response cycle. ⑩ your JWT is coming to you in the header. You're going to find it documented as Bearer <access_token>. That is what's going to come back provided it's not undefined. ① checking to make sure bearer exists ② using "split" which turns a string into an array. With this little device you can isolate the value associated with the "Authorization" value. Remember, that's going to be // Authorization: Bearer <access_token>. You're "splitting" it at the " " between "Bearer" and the actual token. ③ in your array, the [0] value is "Bearer" and the [1] value is your token. So, const bearerToken is going to be your token. ④ setting the request object token to the bearer token. ⑤ keep things moving using "next" ⑥ this is your callback that includes the "req.token" that was established with your "verifyToken" function. ⑦ "secretkey" can be any value. Usually it's a highly random value that is kept confidential and only accessible to your server. ⑧ your "authData" is going to look like this: { "authData": { "user": { "id": 1, "username", "brad", "email": "brad@gmail.com" }, "iat": 1513884407 // iat stands for "expires in" }, } That's the content that was encryped as your JWT on jwt.sign({❽ user}. The way this going to translate to your project is that instead of the "login portion" (⑥ ) that's generating your token, instead you'll have that token embedded in your header. // The way your OpenAPI is going to expect that as something that is stored in local storage in your header. The header title will be "Authorization" with a value of "bearer" and then the token. C) Actual Authentication (back to top...) Using the above as a template, here's the final working code: The above works great! Be aware of the highlighted sections which represent the implementation of the ".env" dynamic where you're definining your signature as a server variable. That ".env" file is in your root directory. 1) user.js (back to top...) The first thing you want to is set up your "user.js" model which will house your username, SSN, DOB etc. You're going to do that by setting up a new database in MongoDB Compass and then initiating a new collection through your "user.js" model in your app. That's going to look like this: const mongoose = require("mongoose"); const Schema = mongoose.Schema; const userSchema = new Schema({ username: { type: String, required: true }, ssn: { type: String, required: true }, dob: { type: String, required: true }, email: { type: String, required: true }, password: { type: String, required: true } }); Notice how you're establishing teh "Schema" constant right out of the chute. As you might expect, this is a package you're having to import on your "app.js" page. That, along with several other packages will need to in place. Let's see what that's going to look like... 2) app.js (back to top...) We're going to break this down into stages... First of all, here are you packages: const express = require("express"); const jwt = require("jsonwebtoken"); const app = express(); const mongoose = require("mongoose"); const session = require("express-session"); const MongoDBStore = require("connect-mongodb-session")(session); const csrf = require("csurf"); const MONGODB_URI = "databaseURL"; The big thing, in addition to all of the crucial things that we've already covered, is the database connection. You'll see referenced at the very end of "app.js" like this: ... mongoose .connect(MONGODB_URI) .then(result => { app.listen(5000); }) .catch(err => { console.log(err); }); 3) Setting Up a User (back to top...) First of all, run your app so the model that you set up with "user.js" establishes the correct columns and fields etc. Next, you can manually insert your user with all of the necessary data with the exception of the encrypted password. To encrypt your password, rather than create a form that captures what's in the database and then use "bcyrptjs" tool, you can click here to do it online. Great way to get it done for the sake of drill. 4) Finding the User (back to top...) The way this is going to work is you're going to use "Postman" to post a user as a collection of Bearer Tokens that will be an encrypted version of the user's DOB and the last four of their SSN. That will be compared to what's in the database and if there's a match. D) Deployment (back to top...) Good PUtty tutorial: https://www.youtube.com/watch?v=_GSOnHRYSS0 E) Authentication w/ Database (back to top...) Final version where we're actually grabbing the corresponding token / info from a database and comparing that value to the incoming JWT rather than hard wiring the token and leaving that potentially exposed. ① this is the functionality that allows you to create and utilize CONSTANTS. In this instance, you're using: SIGNATURE="secretkey" CONNECTION = "mongodb connection" THE_TOKEN = "your token" THE_TOKEN_ID="token id" This is your ".env" file and it's referenced again a few lines later. ② this is the functionality you need to decrypt an incoming JWT ③ the next three lines are constants that you've stored in your .env file in the root directory ④ here, you're importing your authorization.js file which looks like this: const mongoose = require("mongoose"); const Schema = mongoose.Schema; const authorizationSchema = new Schema({ app: { type: String, required: true }, token: { type: String, required: true } }); module.exports = mongoose.model("Authorization", authorizationSchema); ⑤ while this has been covered before, it bears repeating. This whole process of "verifyToken" is to simply define the "req.token" value according to what's coming in via the Header, or at least it was in the previous tutorial. In the tutorial, we were simply ensuring that there was a value and, if so, we "split" it so we could read the token apart from the "Bearer" dynamic. In this instance, we're doing that but we're also comparing that to the token associated with the "_id" of the token that corresponds to the value we have stored as "THE_TOKEN_ID" in our ".env" file. If the incoming JWT is valid and it matches the token that's associated with the "_id" we have stored in our ".env" file, then "req.token"