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.
>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.
I read that you're not planning to integrate with Facebook[1], but what about other providers, if they allow you to request access to almost nothing? Perhaps, for example, allowing people to use <their-name>@github.com would prompt them with a GitHub OAuth screen and identify them. Why not?
I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though.
Great to hear that you continue to iterate on Persona idea. It is a little pity that Portier wasn't announced earlier, preferably together with Persona shutdown decision. Many sites that are using Persona already migrated login flows and would likely consider Portier if it was an option.
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
I think you have just discovered the fundamental flaw of your approach. My only suggestion is send the first email from your own server and if this does not bounce then send again from postmark.
I used to use a telnet based approach to check if the account exists, but most servers these day don't respond with the correct error response if an account does not exist.
The pricing might be prohibitive for your usage. I don't know if any of them offer discounts/free usage for open source projects. (Not endorsing any of them; they've been sitting on my own list of things to investigate.)
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.
Depending on what kind of bounces they penalize you for, making sure the domain has a valid MX record before you send the mail might help.
Won't help if you get flooded with a bunch of invalid usernames at a big email provider, but as your volume of legitimate volume grows the bad ones should hurt less.
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.
Credential Management[1] is newly ratified (or will be ratified soon I lose track at this point. Mike West works fast). Either way, the api is exposed to chrome.
The best I can understand is that Google and Apple both want to store your passwords in the browser/keyring, and sync them between your devices. Apple has begun "suggesting" passwords in Safari that are fairly strong.
It's scary to think about, but "browser" is already the most used "password manager". It just is not full featured yet.
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.
In the long run, authentication should be baked into browsers, and it seems like FIDO U2F is making decent strides in that arena.
For right now, I think Portier hits a sweet spot for smaller sites without a lot of time or energy to put into building out bespoke authentication integrations.
Basically you're asking for an authentication standard.
Some de facto standards are completely client side.
Browsers embed at least the "fill form/remember password" authentication method. It's not a standard and some people use it. Some people use an external password manager instead (I do, keepassx). Some password managers come with addons for the major browsers. Other people don't use anything and try to remember passwords, sorry for them.
Maybe your question was why don't browsers embed oauth?
About the sans cookies experience, with oauth or without it, there should be a standard way for browsers to send authentication info in the request. I don't see another way, but I might be wrong. Basic auth is a way, cookies are another. Both are ok only with https. What do you suggest instead?
Client cert support has been built into the browser for a long time.
One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
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.
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.
> ...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.
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?
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 :/
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.
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?
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...
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...)
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..., 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.
> 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)?
Yes, in the same way that everything is composed of other things.
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.
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.
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.
Here in China more and more logins are using "scan this QR code with your phone". I think this kind of makes sense for places where you really want to login, and it is very convenient.
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.
There's a little more discussion of that over on Lobsters: 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
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.
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, it'll even be a 2-click process to get going.
We do intend to keep 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. ;)
callahad|9 years ago
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|9 years ago
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.
fiatjaf|9 years ago
I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though.
[1]: https://github.com/portier/portier.github.io/blob/master/Non...
mixedbit|9 years ago
callahad|9 years ago
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
danieltillett|9 years ago
I used to use a telnet based approach to check if the account exists, but most servers these day don't respond with the correct error response if an account does not exist.
medmunds|9 years ago
* https://kickbox.io * https://www.emailhippo.com * http://www.briteverify.com
The pricing might be prohibitive for your usage. I don't know if any of them offer discounts/free usage for open source projects. (Not endorsing any of them; they've been sitting on my own list of things to investigate.)
Also, as an aside: SendGrid may not be suitable for transactional email you need delivered consistently quickly, unless you purchase their dedicated IP option. (And if you're bouncing a lot, a dedicated IP could actually be counterproductive for your delivery.) Recent incident [https://sendgrid.com/docs/Classroom/Deliver/shared_ip_thrott...] and discussion [https://news.ycombinator.com/item?id=12142728].
jlgaddis|9 years ago
Having to wait 20 minutes to receive an e-mail so that i can login would be a real PITA.
Also, "recipient verification" (which some others have managed) isn't a good long-term solution.
intimatica|9 years ago
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.
Canada|9 years ago
Won't help if you get flooded with a bunch of invalid usernames at a big email provider, but as your volume of legitimate volume grows the bad ones should hurt less.
eric_h|9 years ago
djokkataja|9 years ago
scottydelta|9 years ago
awinter-py|9 years ago
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.
ejcx|9 years ago
Credential Management[1] is newly ratified (or will be ratified soon I lose track at this point. Mike West works fast). Either way, the api is exposed to chrome.
The best I can understand is that Google and Apple both want to store your passwords in the browser/keyring, and sync them between your devices. Apple has begun "suggesting" passwords in Safari that are fairly strong.
It's scary to think about, but "browser" is already the most used "password manager". It just is not full featured yet.
[1] https://w3c.github.io/webappsec-credential-management/
* you are using chrome
tomjen3|9 years ago
Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
nickpsecurity|9 years ago
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
http://srp.stanford.edu/
Just not getting adoption it needs IIRC. Could be other explanation.
callahad|9 years ago
For right now, I think Portier hits a sweet spot for smaller sites without a lot of time or energy to put into building out bespoke authentication integrations.
pmontra|9 years ago
Some de facto standards are completely client side.
Browsers embed at least the "fill form/remember password" authentication method. It's not a standard and some people use it. Some people use an external password manager instead (I do, keepassx). Some password managers come with addons for the major browsers. Other people don't use anything and try to remember passwords, sorry for them.
Maybe your question was why don't browsers embed oauth?
About the sans cookies experience, with oauth or without it, there should be a standard way for browsers to send authentication info in the request. I don't see another way, but I might be wrong. Basic auth is a way, cookies are another. Both are ok only with https. What do you suggest instead?
closeparen|9 years ago
One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
unknown|9 years ago
[deleted]
aethertron|9 years ago
Xanadu is/was specified to include user authentication. No idea about the implementation there.
kruhft|9 years ago
[1] HTTP Basic Auth
SimeVidas|9 years ago
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|9 years ago
*Though Mozilla supported my work on this, Portier is an independent side project with significant code contributions from folks outside Mozilla.
woodcut|9 years ago
techsupporter|9 years ago
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|9 years ago
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|9 years ago
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 :/
andmarios|9 years ago
namsral|9 years ago
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|9 years ago
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|9 years ago
StavrosK|9 years ago
drdaeman|9 years ago
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|9 years ago
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..., 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.
StavrosK|9 years ago
Yes, in the same way that everything is composed of other things.
fourbnine|9 years ago
overcast|9 years ago
StavrosK|9 years ago
That's why Portier supports other auth providers, so you can have the best of both worlds.
gbog|9 years ago
chaz6|9 years ago
callahad|9 years ago
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
qud|9 years ago
johannes1234321|9 years ago
hossbeast|9 years ago
scrollaway|9 years ago
fiatjaf|9 years ago
callahad|9 years ago
We do intend to keep 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. ;)