Why didn't you choose to implement this feature with a signed token? It would avoid using a db

Because you can't revoke specific signed tokens? I would agree that having something as sensitive as logins without any control over it would not be a great way to implement it.

Because you can't revoke specific signed tokens?

The token would have a very short TTL (like one hour)

I would agree that having something as sensitive as logins without any control over it would not be a great way to implement it

This is how jwt works and so many people are using it (and most of the time this is for wrong reasons, but this is out of topic)

This is how jwt works and so many people are using it (and most of the time this is for wrong reasons, but this is out of topic)

I know JWT and understand that, thank you. That doesn't change the fact the you are passing control over an essential part of your application out of your control.

This feature is fundamentally the same as a "password reset" procedure (as both allow login without knowing the credentials) – and for example Laravel decided to NOT just use signed URLs, but keep using a database-based system: laravel/framework#23706

Maybe there are some arguments that also apply here.

I'm not too familiar with JWT tokens. If you have a token that's valid for 1h, how do you expire this? Usually you'd want a login url valid for maybe 10 to 30 minutes and only usable once. The latter doesn't seem possible with a token that can only expire after time.

Regarding the linked Laravel issue, read laravel/framework#23706 (comment) which makes me think that they chose not to do it because they had an already working solution. But they do point out that having a database has some issues (when the table schema changes for instance). I think it's worth exploring a solution without a DB?

I think it would be beneficial to be able to

• invalidate specific tokens
• allow only a single usage per token

In case of just signed URLs, you could invalidate it by changing your signing secret, but that seems rather excessive. Invalidation after usage doesn't seem to be possible at all.

In this case I would be as careful as possible, as there is no real way back, if you gave control away to the user.
I understand however, that the ease of usage (and the fact that it's optional) shifts the decision in the direction of just signed URLs.

I'm not too familiar with JWT tokens. If you have a token that's valid for 1h, how do you expire this?

You can not natively. If you want to do so, you have to save all rejected tokens in a DB, and for each login (so each API call) you look at your DB if the token is expired. And... you totally defeat the purpose of JWT.

Anyway, JWT is out of topic here :) This was just an example to demonstracte that "signed token" can not be revoked natively

About signed token VS token in DB, I think signed token is good enough.

I totally agree that DB token are more secure though.

BUT Let's be pragmatic. In theory, you can revoke a DB token, but is this a real use case? What would be the workflow?

1. Someone ask a token
2. then say "Oh, now I don't want this token !"
3. Contact the support to delete it,
4. Hope they will delete in within XX minutes (if they don't, anyway the link will not work)

IMHO, it's acceptable to use a signed token with a very short validity (lets say 15 minutes). We could / should mention that flaw in the documentation and that's all. And if someone want something in the DB, they could implement it on their own.

So let's try to summary everything to take a decision:

Note: in the signed token, we could also add the User IP address to increase the security.

very short validity (lets say 15 minutes)

I would advise against using this very short durations because emails can take time to be delivered (eg when the destination server has greylisting enabled)

emails can take time to be delivered

For that reason, I wouldn't include user IP address in the signature either. The probability of changing IPs is not zero if we consider a timespan of several hours.

Hi!

Magic login links are still relatively new and there isn't clear guidance on security aspects. Some people show using JWT (so, links that cannot be expired after a single use) while others are adamant that they must expire after the first use. Reset passwords links should expire after a single use, and a magic link is similar to those.

In the absence of clear guidance, we should see what the biggest services do: both Auth0 and Slack only allow a magic link to be used once.

That is enough for me to think that we should "err" on the side of caution and stored tokens in the database where they can be invalidated after 1 use.

I still think the users will be very easy to implement. In both cases, a Maker command will take care of everything. With a database layer, the only added files are the entity & repository classes, both of which are quite small thanks to a trait in core (and of course, you could implement your own storage layer). In reset-password-bundle we haven't gotten any complaints or pushback yet on requiring persistence.

emails can take time to be delivered

For that reason, I wouldn't include user IP address in the signature either. The probability of changing IPs is not zero if we consider a timespan of several hours.

I don't think we should consider this. Magic login is a login action, it should not take more than 1 or 2 minutes. Otherwise it's not at all UX friendly enough to ever login.

Which is also a reason why I originally considered using the Notifier component here; that would allow switching to an alternative (e.g. sms or notification) using the same authenticator.

This is ready!

Probably the biggest decision is this: should we accept this into core? Or would we prefer this as its own bundle (e.g. symfonycasts/magic-link)?

Regarding where to merge this feature, I think we should have a broader discussion about such features. Would we want to have totp auth in Symfony or rely on a third party bundle? Would we want to have the security bundles from SymfonyCasts in Symfony itself? I can see pros and cons, it's not clear cut to me.

While the features are fairly situational, I'd say the same goes for things like ldap login. I can already think of 2 different scenarios where I'd want to use this feature in my application. I'm not against putting this in a 3rd party bundle, though I think it would be awesome to have it work out-of-the-box in the code of Symfony.

Both solutions are OK to me (because we know that symfonycasts/* packages are of high quality and they will be maintained for newer Symfony versions).

However, I'd prefer to keep this (and other common features) inside the Symfony security package. "Decoupling" every feature and creating "micro packages" would be worse in my opinion (for us to maintain, for us to document, for developers to use, etc.).

I'm in favor of merging this in core.

Regarding the general question, I'd say that only bundles/features that have a strong dependency on third-party libs should live outside of core. It's mostly features that implement complex protocols like JWT, 2FA, OAuth, WebAuthn, ... those are features that should build on robust implementations, proven by crypto/security experts.
For the rest, it's subjective (whether it is common enough, well implemented, and the core team is comfortable enough for maintaining it).

+1 for having it in core as well

This is ready again! I'm quite proud of this version :). The PR description has been fully updated. Highlights:

1. No storage - everything is done with a signed URL (it doesn't actually use UriSigner, but the same concept). The user loading uses the existing user provider system.
2. A cache is used to store "token usage" so that you can limit tokens to be used a set number of times
3. The new signature_properties allows the user to configure which fields on User should invalidate all existing tokens when changed. Common examples would be [id, email, password]. Assuming User::getUsername() returns a true username (not an email or something else), then this would invalid links if the email address changed, the password changed or if suddenly the username were connected with a different "id" in the database. You can even use this to invalidate all existing login links with an extra field on user (I describe this in the PR description).

Cheers!

Btw, this PR should be ready

I really like the new design. I did not review the code (yet) But 👍🏼 for the feature

Thank you @weaverryan.

Hello there, I would like to give my point of view regarding the DB vs Token discussion.

Would it be possible to allow both approaches for this feature ? I do think both approaches are both relevant. In my opinion, I would rather use the database approach. But for some Symfony projects, the app doesn't have its own database (tiny app with in memory user) or authentication is shared cross multiple services. In such case, the token approach would be the only way to go.
I am working on a project where the security is shared cross domain and is managed by a JS middleware even if the user service, which is responsible to validate the password, is written in Symfony. We decided to use a JWT style authentication.

If Symfony decide to support two storages, would it allows switching from one to the other ? Developers would start using database then would want to switch to token (JWT style). For a specific period, they would allow both link storages to not invalidate previously generated links.

security:
    enable_authenticator_manager: true
    # ...
    firewalls:
        # ...
        main:
            # ...
            login_link:
                check_route: 'magic_link_verify'
                signature_properties: [id, password, email]
                # allow both token or database
                default_signature_storage: token
                link_storages:
                    database:
                        enabled: "today < 31 december 2020" # use expression language ?
                        properties: [id, password, email]
                        ttl: 24 hours
                    token:
                        enabled: true
                        properties: [password, email]
                        ttl: 12 hours
                        token_storage: ~ # cache.app | other cache | redis | other ?

If you agree with this, should I create a new feature request to address this improvement ? I'm available on Slack.

Hi!

1. it is “sort of” possible to do database storage with the current implementation. But what’s stored is not the token itself, but a list of tokens that should be invalidated. I’m not sure that’s what you need, but wanted to mention it.

2. in general, what is your need for the database solution?

3. if you do have a valid use case, it would probably be fine to implement an extension point of some sort (not sure exactly what) so that the behavior of the login link handler could work with both the current signed url or a database. A PR would be welcomed. But I’m not sure we would want full integration (I.e. making database storage a first class citizen that you could configure to activate) until we have more people demanding it.

Cheers!

@weaverryan thx for your response. Regarding your point, it is clear to me that my understanding is incomplete. I'll address my points later if needed in other feature request, etc...