search

riverrun / phauxth

Not actively maintained - Authentication library for Phoenix, and other Plug-based, web applications
409 stars 21 forks source link

Thanks for your hard work for 2.0 #103

Closed dsignr closed 5 years ago

dsignr commented 5 years ago

Hi @riverrun , I just came here to thank you for your amazing work for 2.0. I'm using 2.0 in production for two client applications and am extremely pleased with the experience. I haven't faced any glitches or issues yet and I will report them if I hit anything.

One thing though is perhaps a guide or some sample code for new comers to implement OAuth 2.0 protocol with Phauxth as Phauxth can already be used for basic token authentication (basically generating an access_token). If there's support for generating refresh_tokens (which isn't very hard to implement) and manage automatic token refreshes, then, it would be awesome. Would love to know your thoughts on this.

Thanks for the amazing evolving journey - I've been with the library since 0.xx days and watched it evolve to 2.0. This is the best library out there for authentication in the Elixir eco-system, period. Would be really awesome if people don't use insecure JWT based libraries and start using Phauxth more.

Thank you, Cheers.

riverrun commented 5 years ago

@dsignr thanks for your continued support and feedback / encouragement. It is much appreciated.

I have opened a separate issue - #104 - to deal with the matter of refresh tokens. At the moment, I want to research the matter more, so that I can make a more informed decision about what needs to be done.

dsignr commented 5 years ago

Thank you David, I will be happy to contribute to that issue.

x-ji commented 3 years ago

Regarding this topic, I think a general consensus is that the value of having a refresh token is so that access tokens can have a very short expiration time, because they're not checked against a token store in the DB when they're decrypted and verified. If the access token is checked against the DB every time a request is sent anyways, a refresh token is moot, right (i.e. you can revoke the tokens in the DB related to the user once there's a security breach/once the user changes password and wants to log out of all devices etc., just like what you do with a DB session store)? It's not immediately clear to me whether in the current phauxth implementation of token-based authentication, if the token is checked against a DB or not, in addition to being decrypted and verified. I thought a token-based case with phauxth behaves the same way as the default cookie session-based case, but maybe I'm mistaken?

dsignr commented 3 years ago

As far as I know Phauxth doesn't deal at the db level with respect to anything at all. Implementation of token expiration is left to us. But the framework does provide many functions to implement the token expiry portion though.

On Wed, 31 Mar, 2021, 5:34 am Xiang Ji, @.***> wrote:

Regarding this topic, I think a general consensus is that the value of having a refresh token is so that access tokens can have a very short expiration time, because they're not checked against a token store in the DB when they're decrypted and verified. If the access token is checked against the DB every time a request is sent anyways, a refresh token is moot, right? It's not immediately clear to me whether in the current phauxth implementation of token-based authentication, whether the token is checked against a DB or not in addition to being decrypted and verified. I thought a token-based case with phauxth behaves the same way as the default cookie session-based case, but maybe I'm mistaken?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/riverrun/phauxth/issues/103#issuecomment-810655629, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABG4MRHZV73N4TSBR6NU363TGJRJHANCNFSM4GSROXZA .