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'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.
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"
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.
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.
Email filters and autoresponders are a bit convoluted to expect wide adoption. A TXT record might work though. Is a referral in a TXT record any worse from a security perspective than a referral in an MX record?
Manipulating DNS is sadly very easy, but a TXT record of this type should be better than a MX record, as long as a oauth signin also contains a normal login link.
In this case, the worst-case is an attacker injecting a TXT record to force OAuth logins via that domain... which is a bit pointless as far as I can see, it either won't work or use the victim's own oauth service, for which they are responsible themselves IMO.
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.
To me, that sounds like a useful shorthand. It would probably not at all be difficult to add support for that to the broker (apart from the usual wrestling with Rust), so yeah, why not. Though I maybe miss some implications for the RP – breaking the expectation that it is just an email is bad if you use the email as an email, and if you want to have the option to easily move away from portier.
The FB thing was more, iirc, that you don't want to enter an email and then get the FB dialogue just because you used your email on FB.
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.
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.