Hacker News Reader

Comment by jeffbarg | Hacker News Reader

I really love the idea of this - lightweight auth is desperately needed in the web ecosystem (Auth0 is close, but a bit too complicated and bloated).

Would be great if the service returned something like a JWT or just a signed copy of the email address verified (potentially with an expiry date). That way you can use the token itself as authentication without making network calls on the backend to verify it on each call. Not saying this is necessarily production-grade security, but could suffice for small projects where ease-of-use is more important than token revocability.

View on HN

Thanks for the feedback. I totally agree about simple auth.

emauth is intended to be very barebones. On it's own it really doesn't do much. You still need to have some sort of session management on your server. What emauth saves you from is having to worry about generating/storing passwords.

Returning a JWT is an interesting idea. Can you explain more what that would look like? Obviously anything that involves consulting emauth.io for every request isn't going to work. But maybe there would be a simple way for emauth to delegate token verification to your server.

Jwt are usually signed with a private key, and the corresponding public key you need for verification is static/fetchable for dog-and-world.

Not sure why he wants you to implement another oauth server though, there are several quite good (i.e. keycloak) around at this point.

Oh that makes sense. Idk, I think that's actually a good deal simpler than oauth. With a single request you get a token that says emauth.io verifies that at X time the owner of this token had control over Y email address. Anyone can then use emauth.io's public key to verify the claim. This makes the "email whitelist" use case trivial to implement on the server. You just have to have expiration logic.

I don't see how. There are libraries to interface with these oauth solutions so you basically just send them to the corresponding server and wait for them to come back with their token , which you'll verify with said library... You're done

Do you have an example of such a library/service?

I should probably point out that I'm talking about an authentication framework which includes sessions etc. I just can't see any other way for jwts granted by your service to be useful.

If it sounded like your service already exists as an open source solution with libraries for every language... I don't believe it does, it at least I don't know about it.

You could actually implement it with a module in keycloak, but you'd need to write the code yourself. Though it shouldn't be too hard

https://www.keycloak.org/

https://www.keycloak.org/downloads.html

There are community libraries for other languages as well.

And lots of code example for custom authentication flows like

https://github.com/stianst/keycloak-experimental/tree/master...

And an example implementing the auth flow with libraries for a webservice https://github.com/houmie/sso/blob/master/src/app.py

(I'm unrelated to all links, just got them from quick Google searches)

A way it would be useful without sessions is if you have a webapp that loads a list of email addresses on startup. For each request that comes in, it checks if the request has an emauth JWT (maybe passed in a Emauth-Token header). If it does, it verifies the sig, then checks the contained email address against the whitelist. If it matches the request goes through.

Yeah, but how would you log a user out? Delete the local token? And if someone got access to the token, your account will be owned forever with no way to revoke the access. Unless you auto expire them... Now you need a flow to refresh the tokens....

If you implement jwt, you will need sessions and all other features authentication servers have... It would be way easier to implement a custom authentication flows mimicking your email auth than recreating everything else.

I think your service is good as is and introducing jwt to it would be a net-negative

But I'm just a random person from the internet, do whatever you feel like doing ;)

Sorry, I didn't notice you had responded. I think maybe you're reading too much into adding JWTs to emauth.io. It simply provides another source of information, ie that as of a certain time, emauth.io verifies that the holder of this token had control over the email address. Implementations can do whatever they want with that information, depending on their threat model. And since previously the API was returning a fairly redundant text response (status code already tells you whether verification was successful), returning the JWT doesn't interfere with the previous functionality.

Keycloak and CAS for example are popular in the Java ecosystem.

But generally any authentication server that can generate JWTs for authenticated users.

And then with any JWT lib you check the validity (expiration, signature, ...) of the token. See https://jwt.io for a list of libs.

@jeffbarg just FYI I've thought about this some more and I really like this idea. I'm planning to add it. You could have a client talk directly to emauth.io to get a JWT, then they can authenticate against any server that accepts emauth.io-formatted JWTs (probably just email and timestamp). It essentially decouples clients from servers.

Just as an update, on successful email verification emauth.io now returns signed JWTs which currently contain the email address, iss ("https://emauth.io"), and iat. They can be verified using the public key available at emauth.io/pubkey. Thanks for the idea!

Reply on news.ycombinator.com