feature #38177 [Security] Magic login link authentication (weaverryan)
feature #38177 [Security] Magic login link authentication (weaverryan)

This PR was squashed before being merged into the 5.2-dev branch.

Discussion
----------

[Security] Magic login link authentication

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | none
| License       | MIT
| Doc PR        | TODO

Hi!

This adds a Slack-style "magic link" login authenticator to the new login system: (A) enter your email into a form, (B) receive an email with a link in it (C) click that link and you are authenticated!

For most users, implementing this would require:

A) Create a [controller](https://github.com/weaverryan/symfony-magic-login-link-example/blob/master/src/Controller/MagicLinkLoginController.php) with the "enter your email" form and a route for the "check" functionality (similar to `form_login`)
B) Activate in `security.yaml`:

```yml
security:
    enable_authenticator_manager: true
    # ...
    firewalls:
        # ...
        main:
            # ...
            login_link:
                check_route: 'magic_link_verify'
                # this is an important and powerful option
                # An array of properties on your User that are used to sign the link.
                # If any of these change, all existing links will become invalid
                # tl;dr If you want the modification of ANY field to invalidate ALL existing magic links immediately,
                # then you can add it to this list. You could even add a "lastLoginLinkSentAt" to invalid
                # all existing login links when a new one is sent.
                signature_properties: [id, password, email]

                # optional - by default, links can be reused but have a 10 minute lifetime
                #max_uses: 3
                #used_link_cache: cache.app
```

Done! This will generate a URL that looks something like this:

> https://127.0.0.1:9033/login/verify?user=weaverryan@gmail.com&expires=1601342578&hash=YzE1ZDJlYjM3YTMyMjgwZDdkYzg2ZjFlMjZhN2E5ZWRmMzk3NjAxNjRjYThiMjMzNmIxYzAzYzQ4NmQ2Zjk4NA%3D%3D

We would implement a Maker command this config + login/controller. The implementation is done via a "signed URL" and an optional cache pool to "expire" links. The hash of the signed URL can contain any user fields you want, which give you a powerful mechanism to invalidate magic tokens on user data changes. See `signature_properties` above.

#### Security notes:

There is a LOT of variability about how secure these need to be:

* A) Many/most implementation only allow links to be used ONE time. That is *possible* with this implementation, but is not the *default*. You CAN add a `max_uses` config which stores the expired links in a cache so they cannot be re-used. However, to make this work, you need to do more work by adding some "page" between the link the users clicks and *actually* using the login link. Why? Because unless you do this, email clients may follow the link to "preview" it and will "consume" the link.

* B) Many implementations will invalidate all other login links for a user when a new one is created. We do *not* do that, but that IS possible (and we could even generate the code for it) by adding a `lastLoginLinkSentAt` field to `User` and including this in `signature_properties`.

* C) We *do* invalidate all links if the user's email address is changed (assuming the `email` is included in `signature_properties`, which it should be). You can also invalidate on password change or whatever you want.

* D) Some implementations add a "state" so that you can only use the link on the same device that created it. That is, in many cases, quite annoying. We do not currently support that, but we could in the future (and the user could add it themselves).

Thanks!

#### TODOS:

* [x] A) more tests: functional (?) traits
* [ ] B) documentation
* [ ] C) MakerBundle PR
* [ ] D) Make sure we have what we need to allow that "in between" page
* [ ] E) Create a new cache pool instead of relying on cache.app?

Commits
-------

a8afe109d8 [Security] Magic login link authentication

symfony/framework-bundle