Proposal: Rebuild `Auth` App using `mix phx.gen.auth` when `Phoenix@1.7` Ships

In light of the maturity of **`mix phx.gen.auth`** 🎉
(_that **didn't exist** #133 when we originally started building **`Auth`**..._),
I **propose** that we ***re-build*** **`auth`** from first principals 0️⃣
but with a similar goal & feature-set: 🎯 🔐
to enable **1-EnVar Setup^TM** of the ("core") **`App`**. 🚀

# Why? 🤷‍♂️

Why would we do this when our `auth` app already works: https://auth.dwyl.com ??

Firstly, as noted by @SimonLab in https://github.com/dwyl/auth/issues/153 the application workflow is unclear. 😕
If Simon finds it convoluted, then heaven help someone ***`else`*** who is unfamiliar with it. 🤦‍♂️

I find the code _reasonably_ readable because I wrote [much](https://github.com/dwyl/auth/graphs/contributors) of it.
But that's _meaningless_ if the second highest [contributor](https://github.com/dwyl/auth/graphs/contributors) finds it unwieldy.
We need it to be _immediately_ obvious to a **complete beginner** what's going on.

### _Why_ We Built our _Own_ [Custom] `Auth` Experience in First Place ...? 💭

As we've recently seen on a recent **Client** project,
building `auth` directly into the "main" `Phoenix` App adds **`2kloc`** to the codebase
and has nowhere _near_ the level of features, docs or tests this project has.
We didn't want to use **`auth`** for the **Client** project because it's not "polished" enough.
The `auth` that we've built for the **Client** project is _suuupper_ slimmed down; it only has **email+password** and _basic_ verification. No **OAuth** - e.g. [Google Auth](https://github.com/dwyl/elixir-auth-google) which we determined was a [no-brainer](https://github.com/dwyl/elixir-auth-google#fun-facts-) for startups and small B2B apps - `mix phx.gen.auth` has only _basic_ Session Management, No support for being logged in on Multiple Devices, No Roles, Permissions or Dashboards.
Those are the "batteries included" we _already_ have in **`auth`** "v1" and we want for "v2.0".

Our objective is to have a **_seamless_ Auth UX** for people
running the **`App`** on their `localhost` so that we can streamline contribution.

# What? 📝

+ [ ] **Create** an **`/auth` folder** in https://github.com/dwyl/book with various `.md` files e.g. `README.md`, `part1.md`, `part2.md` etc. to capture the journey.
+ [ ] This way we can split out the creation of the app into various 20-min chunks that people read in their own time. The clear advantage: _maintainability_!
+ [ ] Use **`Tailwind`** https://github.com/dwyl/technology-stack/issues/94 for **UI** as it'll be in **`Phoenix v1.7`** ✨
+ [ ] _Specifically_ make it **Mobile _First_** as it's what we will need for our **`App`**!
+ [ ] Use **`LiveView`** where appropriate https://github.com/dwyl/phoenix-liveview-counter-tutorial/issues/74 e.g. "**Who is Online**" via [***`Presence`***](https://hexdocs.pm/phoenix/Phoenix.Presence.html)
+ [ ] Use [**`Swoosh`**](https://github.com/swoosh/swoosh) (_which also didn't exist when we created **`Auth`** originally_)
+ [ ] Keep [**`auth.dwyl.com`**](https://auth.dwyl.com/) as a _independent/separate_ deployed App
so that we can keep the "core" of the [**`App`**](https://github.com/dwyl/app) so that people running it
only have **_ONE_ environment variable** they can get in less than **1 minute**.
+ [ ] Run **`auth`** on TCP Port **`4001`** on `localhost` to make easier to run _both_ the **`App`** on the same machine if the person is busy testing while offline.

+ [ ] Create a comprehensive ***`Admin`*** Dashboard
+ [ ] For ref: https://retool.com/blog/best-laravel-admin-panels/ (but **`PHP`** is _horrible_...!)

At present we have this basic dashboard of the **`people`**: https://auth.dwyl.com/people


> **Note**: just spotted a **`bug`**: **Last Login** is not displayed correctly.

But we could go _much_ further.

e.g: https://auth.dwyl.com/people/3

You can immediately tell from the UI that it's inconsistent and built by someone who is _very_ clearly not a "designer" ... We can do _muuuuch_ better!!

## Potential Enhancements

+ [ ] ["**White-label**"](https://en.wikipedia.org/wiki/White-label_product) it to make it easier for others to re-use it in their `Elixir`, `Phoenix` and _other_ language apps!! Initial success would be _anyone_ else in `Phoenix-land` using our `Auth` implementation, long-term success would be people in `Python`, `Node.js` or even `Rails` using it!
But in the first instance, we just want to make it easier for _ourselves_ to maintain
and others to _contribute_.
+ [ ] Allow inclusion of the Logo via code or **`App`** setup e.g. paste `URL` of a logo.
+ [ ] Automatically verify people who register using an email and password if the redirect URL is `localhost` to speed-up development.

## _How_? 👩‍💻

I propose that in addition to writing a step-by-step tutorial, similar to [/dwyl/**phoenix-chat-example**](https://github.com/dwyl/phoenix-chat-example) etc ...
We use this as an opportunity to create a tutorial mini series of videos that we upload to YouTube!

### Where to Start? > Entity Relationship Diagram (ERD)!

Start by creating a **Entity Relationship Diagram** (ERD) that maps out all the features we've already built in **`v1`**.

The page of the `/tutorial` and first video should be just:
+ [ ] dev environment setup,
+ [ ] `mix phx.new` and
+ [ ] `mix phx.gen.auth` with a
+ [ ] walkthrough of all the code that is created.

Next we can go through the ERD and breakdown the required features.

Will need to return to this later.
But wanted to open the issue to reference it.