5 ms·

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

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.

anderspitman 7y ago
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.
- y4mi 7y ago
  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.
  - anderspitman 7y ago
    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.
    - y4mi 7y ago
      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
      - anderspitman 7y ago
        Do you have an example of such a library/service?
        y4mi 7y ago
        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/ https://www.keycloak.org/downloads.html 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/magic-link 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 https://github.com/houmie/sso/blob/master/src/app.py (I'm unrelated to all links, just got them from quick Google searches)
        anderspitman 7y ago
        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.
  - deleted 7y ago
    [deleted]
anderspitman 7y ago
@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.
- anderspitman 7y ago
  Just as an update, on successful email verification emauth.io now returns signed JWTs which currently contain the email address, iss ("https://emauth.io" https://emauth.io"), and iat. They can be verified using the public key available at emauth.io/pubkey. Thanks for the idea!

anderspitman 7y ago

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.

y4mi 7y ago
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.
- anderspitman 7y ago
  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.
  - y4mi 7y ago
    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
    - anderspitman 7y ago
      Do you have an example of such a library/service?
      - y4mi 7y ago
        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/ https://www.keycloak.org/downloads.html 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/magic-link 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 https://github.com/houmie/sso/blob/master/src/app.py (I'm unrelated to all links, just got them from quick Google searches)
        anderspitman 7y ago
        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.
- deleted 7y ago
  [deleted]

anderspitman 7y ago

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

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