Tech Question: Do we even Need an `AUTH_API_KEY`? 💭 🤷‍♂️

Continuing on from our discussion in: https://github.com/dwyl/auth/issues/268
and with the benefit of our knowledge from `Flutter` and `JS`-land ...
Trying to think about `auth` from first principals ...
_How_ are we going to enable `auth` in our `Flutter` app with the least code possible
and without the need for keeping "secrets" ... 💭

## _Why_ do we have an `AUTH_API_KEY` in the first place?

We (I) created an `AUTH_API_KEY` because I thought that it was _needed_ for identifying/verifying which `App` is using `auth` for authenticating the person. But when I _think_ about it with my [**_beginner's_ mind**](https://en.wikipedia.org/wiki/Shoshin) I'm forced to think "***Why***...?" 🤷‍♂️

If someone is running a `Phoenix` App on `localhost` then we _know_ they are in "Dev" mode, right? 👩‍💻
So _why_ do they _need_ to have an `AUTH_API_KEY` to identify them? 🤔
The `AUTH_API_KEY` doesn't provide the `person` using the `app` any additional security
it's just an extra step for the Dev/Engineer to setup ...

## Does `auth` _need_ an `API_KEY` or can we just do domain-based verification? 💭

Can we just create an "Allowed List" for urls that are allowed to use `auth` and reject any other URL?
We currently require the `URL` to be defined for an `app`, e.g: https://auth.dwyl.com/apps/45


If we are doing a domain-based verification, then do we _need_ an `AUTH_API_KEY`? 💭
What _real_ additional security is the `AUTH_API_KEY` giving us?
Is it just _perceived_ security because we've been trained to think that `API Keys` are the "***right***" way to do this? 🤔

## How will an attacker exploit a system that _only_ has domain-based verification?

Hypothetically, if we were to completely remove the `AUTH_API_KEY`,
how would a malicious person ("attacker") attempt to use our `auth` system
to get people to login with their Google/GitHub/etc account and steal their data? 💭

If the attacker can intercept a request or create a fake page that _looks_ like our `App`,
and use our own `auth` endpoint to authenticate a `person` and then _replay_
the successful `JWT` back to the `App` they can read the `person's` data ...

## How can we do domain-based verification on a _Distributed_ App?

If our `Flutter App` is web-based or deployed to the `App/Play Store`,
will there be a "domain" for it? 💭
And if there is no domain associated with the "Native" App, how do we verify it? 🤷‍♂️
Is there a unique string associated with the `iOS` or `Android` build that cannot be spoofed?

These are the questions that are on my mind right now as I'm thinking about `auth` in _general_
and _specifically_ gearing up to re-write `auth` from first principals to be an order of magnitude simpler.

> **Note**: Please only comment if you _understand_ the security implications of this question. 🙏
i.e: you have done a bit of white/grey hat hacking and understand how "hackers" think about compromising systems. 🦸‍♀️