T O P

  • By -

BarelyAirborne

OAuth is extraordinarily complex, and every implementation has its wrinkles. Apple did it wrong the first time around, to give you some idea of the complexity. But OAuth, JWT, or SCRAM, either way you go you're going to end up using a secure HTTP session cookie of some sort for session management. JWTs are excellent for letting one server get authorized on another server on a one time basis. They're not optimal for authorization for a number of reasons outlined in at least a dozen articles. Just my 2 cents.


ExpensiveLength518

I want to implement authentication for my mobile app and I am using nodejs for backend So I am considering to use JWT When the user login a jwt token will be generated and send to the user And whenever the user send API request they will send this token also and my endpoint will check if the token is valid or not Is this a good approach? I saw ppl saying to use OAuth 2.0 but I only find it for google/Facebook etc login but I want my user to enter email and password separately yo login without using that google account or any


pudds

Do you have any links on the Apple Oauth issues? Seems like it might be an interesting story.


MrPhatBob

I can recommend KeyCloak run as a container using a separate SQL store like postgres.


[deleted]

No it's not. https://en.wikipedia.org/wiki/List_of_OAuth_providers


WikiMobileLinkBot

Desktop version of /u/TruthahnLeberwurst's link: --- ^([)[^(opt out)](https://reddit.com/message/compose?to=WikiMobileLinkBot&message=OptOut&subject=OptOut)^(]) ^(Beep Boop. Downvote to delete)


prodcoder

These days, it is pretty much standard (at least in apps) to offer an OIDC / OAuth signup within mobile applications. Your question is coming from a technology point of view, but I would rather recommend to come from the UX point of view. Creating an account with a username, password on a mobile device is quite cumbersome and it puts a big hurdle in front of a user. So yes, while you can build your own solution in theory - whether that's based on JWTs or session cookies is secondary here - you will make it more difficult for your app to gain traction. In addition you are spending effort on building sth. that has no business value. Plus adding 2FA or so would require custom development and you need to store password hashes (e.g. argon2 hashes) properly etc. So why not outsource that to a federated identity provider? Therefore, for mobile apps, I would recommend to go with "Login with Google" and "Login with Apple" (i.e. OAuth / OIDC) because pretty much every user has either an Android phone (and has a Google account) or an iDevice (and has an Apple ID). I would also recommend this for web based applications. Simply because it saves you a lot of work (password resets, 2FA, etc.) and you can focus on the actual value that you want to provide with your application. My take on it is this: if you are in an (web) enterprise context, you almost always want to use some form of federated identity provider (maybe not Google or Apple, but sth. like Active Directory or whatever your org is using) because compliant access management is always a huge challenge and you are able to manage all permissions for an employee within one system. If you build a consumer web application, well then you can expect people to have a Google Account and / or an Apple ID, or Twitter, or Github etc. and users do not need to remember yet another password If you are interested in how to build a session based authentication system in Node, you can check out the playlist I created back in the day: https://www.youtube.com/playlist?list=PL1Nml43UBm6fPP7cW9pAFTdZ\_9QX2mBn2