
Portier – An email-based, passwordless authentication service - samps
https://portier.github.io/
======
callahad
Hi! A few of us have been hacking on this scaled-down, spiritual successor to
Persona.

The core idea is that you treat this (self-hostable!) microservice like a
black box: email address goes in, validated proof of identity comes out. No
passwords, and no secrets to store in your application’s database. The service
itself is also effectively stateless: aside from caching, the longest lived
key in Redis has a TTL of 15 minutes, and no other datastore is required. So
it should scale pretty reasonably, and be easy enough to administer for
hobbyists.

Behind the scenes, it works similarly to a password reset or passwordless
login workflow, but with progressive enhancement so that, e.g., Gmail users go
through Google Sign-In instead of having to check their email.

~~~
plttn
>Behind the scenes, it works similarly to a password reset or passwordless
login workflow, but with progressive enhancement so that, e.g., Gmail users go
through Google Sign-In instead of having to check their email.

I mean there's really nothing you can do about it, but it doesn't handle
Google Apps / G Suite / whatever today's flavor of white-label Google services
is.

If I use my email which is a Google Apps account, I don't get the Google Sign-
In enhancement, I get an email.

~~~
callahad
We discussed this in [https://github.com/portier/portier-
broker/issues/44](https://github.com/portier/portier-broker/issues/44), and
unfortunately don't think there's a good way to blanket-enable support for G
Suite domains. :(

I'd really love to make this possible in the near future. Maybe an opt-in
flag? Or finishing up our federated protocol and building a tiny service that
bridges between that and G-Suite? Suggestions / feedback into that bug would
be really helpful.

~~~
tscs37
A possible solution would be a DNS TXT entry (some with custom mail domains
will have some sort of access to their DNS), which Portier could look up and
use to determine if the service supports some form of OAuth.

Alternatively, if DNS is not applicable, users could use filters and
autoresponders to send back an automatic response with some code.

In theory that would basically mean "Portier sends Login Mail" -> "Login Mail
gets bounced via filter with additional code" -> "Portier constructs OAuth
Link" -> "Portier sends OAuth back"

~~~
Vendan
An auto responder wouldn't have access to the user that made the request's
cookies, and therefore would be unable to actually authenticate the user.
You'd wind up with a system where anyone that knew your email would be able to
log in as you, which is a rather bad idea.

~~~
tscs37
The autoresponder is more of a "This domain accept OAuth" and sends back the
email body.

That way, the autoresponder doesn't need to know anything about the process
nor does it authenticate the user.

It merely sends back a mail that portier can interprete as "Ok, I send an auth
email there and this response means they want me to construct an oauth link to
this domain"

it's stateless and only requires a rather simple autoresponder that can
include email bodies.

Furthermore, portier can also verify the login link, so that replay attacks
aren't feasible and the sender and link-owner must have matching emails.

------
callahad
Postmark just dropped our outbound email for high bounce rates. Falling back
to SendGrid :/ Try again in 5 minutes.

Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means
people are spamming the login form with bogus addresses like a@a.com that
bounce and cause trouble for us and the ESPs. Not ideal, but I'm not sure how
to solve this for a small scale side-project. Discussion in
[https://github.com/portier/portier-
broker/issues/96](https://github.com/portier/portier-broker/issues/96)

~~~
intimatica
What about only explicitly allowing domains that have DKIM enabled?

Having that form of validation should help since DKIM was made to specifically
stop email spoofing; and anyone serious about implementing Portier would
understand that need.

Outlook/Gmail etc aren't likely to be flagged by ESP's for the most part as
those have reputation and rudimentary spoofing protection, at least more than
a@a.com anyway.

Persons using custom domains are usually the admins of those domains, and
Office 365/GApps/Registrars etc. provide simple ways to enable DKIM.

~~~
jlgaddis
In response to your other (dead) comment, "SPF" records actually are TXT
records.

In the past, there was an SPF RR type but that's been deprecated.

------
awinter-py
Real question here is 'why isn't auth built in to the browser'. Lack of
browser support is the reason oauth is so complicated (it relies on HTTP
redirect to pass information around).

Imagine a web experience sans cookies and sans JS. If you take into account
the economics of content, it can only happen with browser-mediated login.

~~~
tomjen3
It is, and has been since god knows when: client certificates. Better than
passwords because they can't be phised, doesn't require an email, doesn't
require trusting any third-party service.

Unfortunately they are also very difficult to understand for even normal geeks
and so basically no site use them.

~~~
drdaeman
It's not hard to understand ("you have the key, in a form of file or a
hardware token, use it to open your account" is something average grandma can
grok - no harder than passwords), but current UI and UX are terrible. Then
it's chicken-and-egg problem: no one uses certificates because they're
unuseable, and no one works on their usability because no one uses them.

------
SimeVidas
Note that Mozilla Persona did not support passwordless authentication.
Specifically, you would still need to create a Persona password if you didn’t
use a Gmail/Yahoo email address.

I’ve tested this service with one of those 10-minute emails and it seems to
work without any passwords, so true passwordless authentication.

~~~
callahad
Yep! Requiring a separate account for Persona was, in hindsight, misguided.
I've written a bit about what Persona got right and wrong, and how we* plan
for Portier to be different, at
[https://github.com/portier/portier.github.io/blob/master/Oth...](https://github.com/portier/portier.github.io/blob/master/OtherProjects.md#portier-
compared-to-persona)

*Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.

------
woodcut
I tried purely email based authentication in the past, unfortunately our
domain for whatever reason wasn't deemed beyond reproach by gmail et al. At
first it they blocked around 5% of emails eventually this went up to nearly
9%, aside from those that got blocked some just disappeared into a void after
being accepted by gmail and took upwards of 20 mins to a few hours to be
delivered.

~~~
techsupporter
> ...unfortunately our domain for whatever reason wasn't deemed beyond
> reproach by gmail et al. ... aside from those that got blocked some just
> disappeared into a void after being accepted by gmail...

This is why I have started to really loathe GMail. I get that spam is a
problem but, periodically, Google decides to shit-can e-mails from me to their
subscribers with no notification to me or the recipient. I know for an
absolute fact that no one sends spam from my server because I'm the only
person who uses that server and it has no mail-sending scripts on it. My DKIM
and SPF records are configured and working, my sending IPs have been
consistent for years, and my domain's registration predates the existence of
Google[0]. But still, every 4 months or so, Google decides to get its hackles
up for a few days and then everything goes back to normal.

0 - This is maybe one reason that compounds my frustration because I've been
on the Internet long enough to remember when this wasn't a problem and when
mail admins could talk to each other to resolve things like this.

------
shazow
Is there a process for migrating to a different email address?

Let's say I used my work address to sign into a bunch of stuff, but then I
leave my job and I lose access to my email address? Or say I'm migrating from
using @gmail.com for everything to using my own domain?

~~~
callahad
Portier is an implementation detail for the websites you're using -- it
doesn't do anything but validate addresses, and it doesn't have any kind of
persistent database. It'd be up to the sites you're using to have some sort of
address changing mechanism, just as if they were using a traditional
username/password system.

One tradeoff of Portier's approach is that you can't authenticate if you lose
access to your email account. This can be a pain in the ass in some cases, but
beneficial in others -- pull someone from your company's LDAP and they can't
represent themselves with that email address anymore. Tradeoffs :/

~~~
WorldMaker
This was a criticism I heard a bunch while I was trying to evangelize Persona.
Persona and Portier almost replace all of the guts of a user database, except
for small needs of user profiles (which will likely forever be site specific)
and user continuity, which is a much bigger issue and the source of the most
pushback against Persona I heard from potential site owners.

User continuity and conjunction (as a user here are three emails that all
represent "me"; this one I used in the past but cannot access now; this one is
my "primary") is definitely a complicated problem and there are definitely
some domains (corporate) that need to be stricter with what they allow than
others.

The best argument I found was that all of the major website frameworks in use
today (Rails, ASP.NET, Laravel, Django, what have you) provide in the box
solutions for user continuity given the existing "standard" of
username/password connected to an assortment of email addresses and/or OpenID
Connect connections. The easiest way to implement Persona (or Portier) in most
frameworks and continue to take advantage of built-in user continuity was as
"yet another vaguely OpenID Connect"-like option in the potential giant wall
of login brands, which means that it competes with Facebook/Google/GitHub/et
al login for mental brand space.

Obviously there is no "easy" answer here, but it would definitely help sell
Portier to potential sites if there were some answers. Perhaps some sort of
user continuity service (or service options) would be useful as another
microservice in a "Portier ecosystem" even if it is just barely on par with
the built-in templates of the average web framework today. That could help
make it easier to "sell" it as a drop-in replacement for all of the bulky
weight of web framework user systems rather than "yet another login option in
a sea of them".

------
andmarios
Cool! Caddy webserver supports something similar I think —minus the google
sign-in:
[https://caddyserver.com/docs/multipass](https://caddyserver.com/docs/multipass)

~~~
namsral
Hi, I'm the dev.
[https://github.com/namsral/multipass](https://github.com/namsral/multipass)

Multipass is email provider agnostic, any email address can be used to
authenticate users without a password. It's up to the service maintainer to
handle authorisation.

Multipass is available as a Caddy plugin, a single binary and can be included
in your Go project.

------
fiatjaf
Is it possible to create an email-like service that doesn't actually handle
email, but only serves as an identity endpoint to be used with Portier?

Like, say, I create an account that reads "me@fiatjaf.com" and implement
something on my fiatjaf.com server so that I can use it to login using
Portier?

~~~
callahad
It will be! We're not sure what the eventual protocol will look like, but
it'll probably start with webfinger, which can then point to whatever
authentication gateway you want. We only need SMTP as the base case in the
chain of strategies:
[https://github.com/portier/portier.github.io/blob/master/Des...](https://github.com/portier/portier.github.io/blob/master/Design.md)

~~~
fourbnine
At the risk of stating the obvious choosing webfinger implicitly excludes
anyone who does not or can not control their website sufficiently to implement
webfinger. (ie: hosted webservices similar to Tumblr et al)

~~~
fiatjaf
That's perfect.

If you do not own the domain you shouldn't be able to use the domain like
that.

~~~
fourbnine
Owning the domain is not the same thing as fully controlling the web service.

My use of Tumblr as an example rather than simply stating hosted-CMS has
probably misconstrued my point. (I use Tumblr with my own domain and forget
that it is primarily not used that way.)

~~~
WorldMaker
Right if your domain is simply CNAMEd to a Tumblr or Blogger or similar hosted
CMS you probably have no way to get webfinger in place.

Another example here is any domain that uses static hosting. Lots of domains
are hosted on GitHub Pages these days as the obvious big example (but you can
replace that with any other static host like Netflify or raw S3 even). The
webfinger spec uses query strings to differentiate user requests which means
that a static hosted site is at best limited to a single user/email account
(by ignoring the query string and returning a static JSON document).

------
drdaeman
Maybe I'm heavily misunderstanding how this whole thing works, but isn't it
basically a django-allauth/passport.js/omniauth/... packed as a
[micro]service, with an "click link in email" for the fallback algorithm, and
a planned "self-hosted" option (not sure how it would be any conceptually
different from classic OpenID)?

Calling this a spiritual successor to Persona looks like a big stretch to
me... Maybe I got it all wrong, though.

(And still I don't like it anyway, because my pet peeve is not having identity
_providers_ at all - one's identity must be something they can actually _own_
, not something they lease from a provider, be it an email service or domain
registrar...)

~~~
callahad
Yes. It's multi-provider authentication as a service.

I think this matters, since it means I can run a single instance to support
_all_ of my projects, regardless of language, because everything speaks HTTP.
I don't have to grapple with OmniAuth for Ruby, AllAuth for Python,
Passwordless for Node, and lord knows what for experiments in Clojure, Elixir,
and Rust. I don't have to set up outbound email, register social API keys, and
design a hybrid login form for each of those projects, either. Set up Portier
once, and I'm done. I've written more about Persona's failings and virtues at
[https://github.com/portier/portier.github.io/blob/master/Oth...](https://github.com/portier/portier.github.io/blob/master/OtherProjects.md),
which might better explain why I view this as a successor.

As to Identity Providers... as long as websites utilize email addresses as a
way of identifying accounts and resetting passwords, we're in the same place.
Portier makes this no worse. I sympathize with the notion that identity should
not be leased from a third party, but I don't know how to solve that.
Blockchains? I'd encourage others to pursue that future while Portier tries to
carve out an ephemeral but useful island in the present.

~~~
drdaeman
> Yes. It's multi-provider authentication as a service.

I see. Thanks for clarifying!

I just thought Persona was about privacy (IdPs unaware about identity
consumers), and potential browser integration - this was its good points. So,
when comparing to Persona, this one looks pale to me.

> Blockchains?

TBH, I don't see any necessity to prove chronologies or require global
consensus, unless a globally-unique human-readable identities (like email
addresses, but actually owned) are desirable. But are they? I mean, when I
walk in some company's reception desk, I don't normally show them some
universally recognized ID, I just say "hi, I'm your customer, we had business
before - you know me as Aleksey".

Just that I believe it's good to have an authentication protocol (something
better than usernames-and-passwords) that is universally accepted, rather than
an universally accepted identity. Do you know, does general audience wants it
differently?

------
fourbnine
I hope the needs of providers like Fastmail (who provide services at users
domains) are top of mind for the people behind this project as it's difficult
to see it getting traction if it can't be deployed en-mass by hosting
providers.

------
overcast
I dream of the day all logins are just simple tokens. Either sent through
email, or SMS. So sick of passwords. I've used other Passwordless libraries on
a few projects, and it's almost cathartic.

~~~
StavrosK
The problem with that is that it breaks a user's flow too much :/ It's a good
fallback, and it has many benefits, but having to switch contexts to the mail
client and wait for an email is too cumbersome for the user (although it's not
too bad when paired with a long-lived session).

That's why Portier supports other auth providers, so you can have the best of
both worlds.

~~~
Sir_Substance
>The problem with that is that it breaks a user's flow too much :/

Unironically and without rancor, would you say it breaks a users flow more or
less than having to go fire up their password manager and find the service
from dozens of entries?

The number of services we use daily is increasing, and they just keep getting
hacked. The idea of actually memorizing your password is rapidly becoming
impractical. Most people these days who understand password security have
either developed a personal algorithm for deriving passwords, or use a
password manager for literally everything.

I'm super glad someone has done this, because it means I don't have to get off
my arse and do it, and lord knows I love laziness.

Generally speaking, for websites that I log into less than once a month, I
reset my password every time I log into them, and set it to a random and long
keyboard smashing every time I do so. This is the same workflow, but without
having to use notepad to stage the new "password" for entry into the
confirmation field.

~~~
StavrosK
> more or less than having to go fire up their password manager and find the
> service from dozens of entries?

Definitely more. All good password managers are so well integrated that the
username and password are pre-filled in most sites noawadays.

> Most people these days who understand password security have either
> developed a personal algorithm for deriving passwords, or use a password
> manager for literally everything.

Yep, passwords suck.

> This is the same workflow, but without having to use notepad to stage the
> new "password" for entry into the confirmation field.

Exactly. This just removes all pretense.

------
chaz6
This sounds an awful lot like OpenID (2). What makes it different? My OpenID
login (aka XRI i-name) is "=chris.hills" and works on sites that support it.

~~~
callahad
There's a little more discussion of that over on Lobsters:
[https://lobste.rs/s/fkosun/](https://lobste.rs/s/fkosun/). The TL;DR is that
URIs just didn't work for the mass public. You had to supplement the login
form with a NASCAR-esque wall of logos, which was awful for different reasons.

Thus, Portier, and Persona before it, chose to identify users by email
addresses. I talk a little bit about that at 9:05 in my PyCon 2013 talk on
Persona:
[https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05](https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05)

------
qud
Emails are not unique, lots of companies assign employees emails that would
later be used by another person.

~~~
johannes1234321
That is an issue not spezific to this tool. It's an issue with all tools
offering "Lost password" features. Nowadays everybody should be able to get
personalized mail addresses.

------
hossbeast
How do you pronounce it?

~~~
scrollaway
Por-tee-ay

------
fiatjaf
Are there any free public servers we can use for side-projects?

~~~
callahad
We're literally running this on a hobby-tier Heroku dyno, with free-level
redis and smtp services and doing fine at the tens-of-requests-per-minute
rate. So you should be able to host your own! :) Once we implement
[https://github.com/portier/portier-
broker/issues/88](https://github.com/portier/portier-broker/issues/88), it'll
even be a 2-click process to get going.

We do intend to keep [https://broker.portier.io](https://broker.portier.io)
online as a public service / reference implementation, but we don't have
anyone on call or anything if it falls over. On the upside, the Broker is
written in Rust, so it shouldn't segfault all that often. ;)

