Live data from Hacker News

Portier – An email-based, passwordless authentication service

portier.github.io

11–20 of 89 posts

Re: Portier – An email-based, passwordless authentication service

#11
post #8

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…

>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.

Re: Portier – An email-based, passwordless authentication service

#12

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.

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.

Re: Portier – An email-based, passwordless authentication service

#13
post #11
post #8

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…

>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 accoun…

We discussed this in 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.

Re: Portier – An email-based, passwordless authentication service

#15

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.

Re: Portier – An email-based, passwordless authentication service

#16

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.

Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.

Re: Portier – An email-based, passwordless authentication service

#18
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?

Re: Portier – An email-based, passwordless authentication service

#19

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.

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.

Re: Portier – An email-based, passwordless authentication service

#20
post #17

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

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. ;)

Post reply on HN