Recently, one of our customers came to us with a problem; their email campaign links all required an authenticated user.
As a result, a significant portion of users abandoned the email campaign.
They clicked on a link to see an offer and were met with a login screen, providing a poor user experience and also a smell of phishing.
Our client wanted to be able to increase the effectiveness of their email campaigns by allowing users to authenticate without the need of a password.
To achieve this, we used a passwordless approach, similar to that of the blogging platform Medium. Using this method, our client could choose a group of users, generate campaign links, complete with tokens, that could be used to automatically authenticate as the target user.
This involved creating a piece of middleware for use with IdentityServer4 that worked in tandem with an administration API service used to create and manage email campaigns (which itself was protected by IdentityServer).
To create a campaign, our customer sent the administration API some basic details about the campaign, including a list of email addresses that they wanted to target.
In response, two links where returned: one to activate the campaign link (triggered on email open) and one to use the campaign link.
By only activating the link upon email open, which in turn triggered the link expiration, we could minimize the risk of a user forwarding the email to another person, possibly resulting in impersonation. Our customers preferred link lifetime was 10 minutes.
These links were scoped to an individual user, a specific campaign link, and had a defined expiration from both generation and activation.
When the user clicks the link, they are sent directly to IdentityServer where their token is validated. Assuming the token is valid and activated, and that the campaign itself is active, then the user will be automatically authenticated and redirected to the final campaign destination.
If the token is invalid, expired, was not activated, or the campaign was not activated, then they call back to authenticating by the login screen.
To further minimize the risk of the tokens being forwarded or used maliciously, we could take advantage of the OpenID Connect identity token's amr (Authentication Method Reference) value.
When using this passwordless style authentication, you could set an amr value of "passwordless" and then have your client applications only display a limited amount of personal information, or to perform a smaller subset of administrative tasks. For instance, I wouldn't be comfortable allowing someone who authenticated using passwordless to change their password on that level of assurance. Instead, I would challenge them for their username & password, and potentially a second factor.
We're proud to be a Certified B Corporation, meeting the highest standards of social and environmental impact.
+44 333 939 8119
