1. 61

Hi Lobsters! A few of us have been hacking on a scaled-down, spiritual successor to Persona, and we think it’s far enough along to show off and get some validation of the idea / architecture.

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.

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. We’d love to know what you think!


  2. 5

    Hey, seems like a nice idea, but how is it different from OpenID?

    1. 9

      In addition to what Dan said, email addresses are much better UX for users. OpenID had huge issues with users not understanding how a URL could be their identifier, which we hope to avoid with Portier.

      1. 7

        UX for users.

        Developers too… I’ve worked with many a developer who had issues with the OpenID, OAUTH, &c. workflows, so these is pretty intriguing.

        1. 4

          UX for users.

          Developers too…


          1. 2

            That would be a great name… I’ve thought about it when I’ve been working on APIs or languages or tools for languages: what is the user experience for a developer who is using this thing? What can I do to make this thing more pleasant to use? Languages like Elm have great “UX”, whereas tools like Burp & ZAP have terrible UX for analysts. DX is a neat condensation of that…

            1. 3

              I agree. I think developers tend to be more accepting of tradeoffs in usability in exchange for capability, which makes designing for them somewhat different from designing for end users.

      2. 6

        In some ways, you can think of Portier acting as an adapter in front of other OAuth / OpenID providers, so you integrate with Portier once, and get consistent support for other providers for free. More in the design document.

        The other big difference is that Portier asks users for an email address, and provides a fallback which ensures that Portier works for all email addresses. This is a huge improvement over classic OpenID, which used opaque URLs for identities, and OpenID Connect, which effectively requires every website to pre-register with, whitelist, and display custom buttons for specific OAuth providers.

        Portier is just email in, auth out, using whatever protocol is most appropriate for that email domain. Way more humane for users.

        Otherwise, most of the virtues of OpenID should carry through. There’s deeper discussion of how Portier compares to Persona in OtherProjects.md.

      3. 5

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

        Edit: Ask Lobsters: Any suggestions for solving this? Hitting the frontpage of HN, et al. 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

        1. 4

          Congratulations on launching!

          1. 3

            I think this is interesting… until people start attacking DNS or the like. I don’t even mean in terms of Mirai or the like… I mean things like what happened to Kenneth Reitz. Those sorts of attacks aren’t even theoretical, or even necessarily intentional; I had a large financial services client do an entire rebranding effort, walk through the entire setup of creating new brand data, &c. … only to completely forget to register the domain name. They were already handing out email addresses to someone else’s domain.

            tl;dr: I think it’s a neat idea, and I’d love to see where you go with it, but as a security person, these sorts of things scare the tar out of me.

            1. 6

              I hear this a lot, but what people don’t realize is that this is no less secure than what we’re doing now. If someone hijacks your email provider’s DNS, you’ve already lost, no matter how secure your password.

              I guess the problem is that centralized authentication this direct doesn’t sit well with people, whereas the existence of the “reset your password by email” link is easier to ignore, even though it’s exactly the same as something like Portier.

              1. 3

                oh I agree it’s not any less secure; we argue about password reset links all the time at work, for example. It has all the same security risks as password reset links, or what slack is doing with “magic links” to login.

                It’s just that I sit on the side of the fence that password reset links are terrible too, depending on your risk level. I think for most things this is an intriguing fix to a problem and I’d like to see it work. I think the difference is that I work in government and high-finance and email is considered at best a necessary evil.

                Again, super interesting idea, and I’m curious to see where you go, but I probably won’t see it in my domain for a while yet (if ever).

                1. 2

                  I am not a Slack engineer, but unlike generic password reset links, the Slack “magic links” does not need to have the same vulnerability as Password Reset Links (whether or not it’s vulnerable in practice is a separate issue, as I’ve mentioned I don’t work for Slack…).

                  Here’s the secure scenario:

                  1. The Slack app (which is considered “trusted”, in this context) issues a request to login to the Slack backend server with a one time token generated for that request, and Slack uses that token to sign a generated “magic link”, which is sent to the user’s email address.
                  2. The user opens their email, and clicks on the link, which directs them to their mobile browser with a deep link that triggers the Slack app to open on their device. The Slack app (which still remembers the token it used), confirms that the URL is indeed signed with the same token.
                  3. To close the loop and enforce that only the originating device/app can log in, the Slack app signs the magic link with the original token and sends a login request to Slack’s backend server.
                  4. The backend server can trivially check that the final signed link was hashed twice with the same consistent token.

                  If our primary attack vector is email interception (between steps 1 and 2), then we can guarantee that the magic link alone will not authenticate them on any device other than the originating device because the imposter lacks the original token to close the loop and sign the final request (step 3).

            2. 2

              Is this similar to the slack magic link login experience?

              1. 3

                It’s a bit similar, but Portier first tries to use a few in-browser, federated authentication strategies before falling back to magic links. Like magic links, it still works for everyone, but for a lot of folks, they never even need to check their email.

              2. 2

                I’m 100% behind this, though before I’d adopt it I want to see how the decentralization will happen. Who does the discovery of custom portier brokers?

                1. 2

                  Thanks! Unlike Persona’s unfortunate reliance on a single fallback / bridge at login.persona.org, Portier is designed to be decentralized from day one: hosting your own broker in support of your own websites should be trivial. It effectively becomes an implementation detail that you can share between multiple domains. Like your own personal Auth0.

                  The trick, then, is how your broker will discover other domains that support OAuth-style authentication, so it can authenticate users with that instead of the email loop fallback. We’re not sure how to solve this yet. Webfinger will likely play a role, but the specifics haven’t been ironed out. We talk about this a little bit in Design.md and in portier/portier.github.io#13.