rishabhpoddar

7 ms·

1. 61.▲
   by rishabhpoddar 4y ago

   There are other differences too: - Our architecture is different: We provide a frontend SDK with react components that are embedded in your own website - giving you more control and a better dev experience. The frontend doesn't talk to
2. 62.▲
   Show HN: Open Source Authentication and Authorization

   128 points by rishabhpoddar 4y ago|33 comments
3. 63.▲
   by rishabhpoddar 5y ago

   Another big factor is the availability of hiring talent. But I guess this already comes under the popularity point.
4. 64.▲
   Implementing a forgot password flow (with pseudo code)(supertokens.io)

   2 points by rishabhpoddar 5y ago|0 comments
5. 65.▲
   by rishabhpoddar 6y ago

   For example, if you require email / password auth without SSO, then we do not use open ID connect or any of the oauth flows - because those are not needed in a simple setup.
6. 66.▲
   by rishabhpoddar 6y ago

   One important point is that we do not follow the OAuth 2.0 protocol since for simple email password login without SSO, we do not need to provide OAuth. So the login part, is a simple API call with the email / password. On success, a se
7. 67.▲
   by rishabhpoddar 6y ago

   Yes. It was using HMAC. But I would still assume that RSA would be much faster than a db lookup (in a distributed system)?
8. 68.▲
   by rishabhpoddar 6y ago

   This is a debatable topic. We wrote a blog post about this as well: https://supertokens.io/blog/are-you-using-jwts-for-user-sess...
9. 69.▲
   by rishabhpoddar 6y ago

   Thanks for the encouragement :) We will be happy to help when you get started.
10. 70.▲
    by rishabhpoddar 6y ago

    Oh! Thanks for the heads up! I have created an issue about this on our github, referencing this comment.
11. 71.▲
    by rishabhpoddar 6y ago

    Thanks for the comment and disclosure :) We do intend to be a full featured solution. Though, since we are relatively new, we only provide email and password. That being said, our approach is modular in nature so that users get only what th
12. 72.▲
    by rishabhpoddar 6y ago

    Thank you! Really appreciate your kind words :) Have a great day
13. 73.▲
    by rishabhpoddar 6y ago

    So the core is written in Java. The core is a http microservice that contains the main auth logic + interacts with the database. The backend API queries the core for sign in / sign up / sessions etc... This can be in any framework
14. 74.▲
    by rishabhpoddar 6y ago

    We don't have that unfortunately. However, a quick hack is to upvote an issue related to the feature you like the most, or create an issue in case it does not exist. But thanks for the idea! It's a great one.. will have a look at
15. 75.▲
    by rishabhpoddar 6y ago

    Hahahaha. Fair enough. And it get's even worse when talking about sessions and tokens...
16. 76.▲
    by rishabhpoddar 6y ago

    Thanks for the heads up!! We will fix this ASAP.
17. 77.▲
    by rishabhpoddar 6y ago

    We plan on supporting it, but don't have a definite date for it as of yet.
18. 78.▲
    by rishabhpoddar 6y ago

    We have SDKs for other backend frameworks as well (like golang, laravel...). But those only have a session feature, and not login. Hope this provides some clarification.
19. 79.▲
    by rishabhpoddar 6y ago

    The SuperTokens microservice is in Java. The backend can be in anything (like nodejs) - for which we have an SDK that developers interact with.
20. 80.▲
    by rishabhpoddar 6y ago

    This is a complicated decision to have made and perhaps a blog post is needed for this. But here is an attempt to answer it: A complex enough app will require modifications to the auth flow. Most services achieve that via webhooks or by for
21. 81.▲
    by rishabhpoddar 6y ago

    I understand your confusion. You are right, we need to improve our explanation. A recipe is essentially an auth experience. So auth with email + password (with forgot password & email verification) is a recipe. Social login is another r
22. 82.▲
    by rishabhpoddar 6y ago

    For now, it's just email, password login, with forgot password flow and secure sessions. Email verification is next followed by social login :) Thanks for your feedback
23. 83.▲
    by rishabhpoddar 6y ago

    Yea! Integrations with OSO makes sense! We do have plans to support language specific client libraries.
24. 84.▲
    by rishabhpoddar 6y ago

    1. Right now, we only support email + password login. But plan on supporting MFA soon. The exact supported methods are TBD. 2. The reason that happens is because we do not use iframes for the login UI. We provide a React component instead.
25. 85.▲
    by rishabhpoddar 6y ago

    Thanks for your comment :) > What is the usecase for supertoken instead something like identity server for .net, whatever Java spring uses or something like django or flasks authentication? We plan on building a much more feature rich au
26. 86.▲
    by rishabhpoddar 6y ago

    Simpler and open source AWS Cognito.
27. 87.▲
    by rishabhpoddar 6y ago

    Yea for those that do not trust a third party, we also offer a self hosted version in which all the data is stored in your own db.
28. 88.▲
    by rishabhpoddar 6y ago

    Thanks for the valuable suggestions! Email verification is next on our list of features. We plan on providing an "active" method which requires you to verify the email to sign up, and one "passive" method which reminds y
29. 89.▲
    by rishabhpoddar 6y ago

    Yea! Absolutely. Both our solutions follow the same fundamental idea of changing tokens to detect theft. That being said, there are edge cases that need to be considered when detecting token theft such that there are no false positives: ht
30. 90.▲
    by rishabhpoddar 6y ago

    Thanks for pointing it out :)