This is my earnest effort to write an intro to OAuth that is aimed at being useful to CEOs, engineering VPs, sales, etc. Any feedback is very much appreciated!
Stateless JWT is useful in the scenario where one server is capable of authenticating a user (through password, social login, one-time password, etc.), and a different server holds resources that the user is trying to access.
The server doing the authentication will issue a stateless JWT with all the user credentials cryptographically signed, so that the user can pass the JWT to the server holding the resource to be granted access, assuming that server trusts the authentication server to perform authentication correctly.
Stateless JWT is useful here because the server holding the resources can verify the credentials of the user without contacting the authentication server.
Regarding OAuth, there are 2 sides to it. You can become an OAuth provider, which I reckon you are not interested to be. What you may be interested is to use OAuth to enable users of OAuth providers like Facebook, Twitter, .etc, to access your service, so that you minimize what you have to develop in terms of user management, i.e., you don't have to worry about user creation, email verification, password resets, etc., because all those have been performed by the OAuth providers.
I believe passport.js allows you to use OAuth to allow OAuth providers' users to access your service. passport.js may be a backend-base solution so you have to be somewhat familiar with OAuth to get started.
Alternatively take a look a https://oauth.io, which has a front-end based solution; I am not saying a front-end based solution is better, but rather it's easier to understand for someone starting out. Moreover they have JS fiddles that you can instantly play around with.
Check out the JS fiddle for creating a 'Login with Github' for your website here in just a couple of lines of Javascript: https://jsfiddle.net/dg9h7dse/1/
It may be but probably not that soon since there are a lot of countries not on smartphones, some industries have multiple dominant players, and users may not want to deal with an app from each player, e.g., car dealers, etc.
Yeah. Every single action is tracked these days, and almost every channel is utilized as a marketing attempting; some channels are just very well disguised or they do provide some value/amusement that they are sort of welcome or at least tolerable.
Basically for people who are interested to understand Relay/GraphQL's global node ID covers:
* What is the mysterious NodeDefinition interface?
* What is Node ID?
* When is it created?
* When is it used?
There are 2 perspectives to be aware of: theirs & yours.
You are replacing something they wrote. That in a way is saying what they wrote is obsolete.
Ask yourself why are you and other new members are working on this project; for your own advancement or for the good of the company. If the reason is the former, there's going to be a big ego-clash.
Look for win-win:
* The original team wrote the system and have learned valuable lessons from it over time. Ask them if they could write it now using current tools, how would they improve. Sell them the vision that the success of the project depends on their knowledge, and they can learn new tools, language, patterns, from the new members.
* The newer members can bring new ideas (backend, UI, etc). Sell them the vision that the success of the project depends on the new skill set that they bring.
Since you cannot change the original team composition, balance it by choosing the new team carefully, e.g., choose people who are goal-driven, and result-oriented; they care more about getting things done then throwing their weight around.
Use Facebook's plain vanilla Flux implementation on Rails if you are worried about specification conformance, and future support of other gem-based Flux implementation.
