Alternatives to JSON Web Token

As the access to our global REST-API "Charon" is bound to OAuth2, we use Keycloak inside Quarkus to authenticate and authorize users of our API. It is not possible to perform any un-authenticated requests against this API, so we wanted to make really sure that the authentication/authorization component is absolutely reliable and tested. We found those attributes within Keycloak, so we used it.

My teammates and I are arguing on which library to use for our local and social authentication in our express app between OAuth2 and Passport. I went for Passport cause I personally like it, and it seems easier to implement with good docs, but some of my teammates think it's less secure than OAuth2. So any advice please would be appreciated. Thanks 🙏🏻

Repost

Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku. However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

Hey all, We're currently weighing up the pros & cons of using Firebase Authentication vs something more OTB like Auth0 or Okta to manage end-user access management for a consumer digital content product. From what I understand so far, Something like Firebase Auth would require more dev effort but is likely to cost less overall, whereas OTB, you have a UI-based console which makes config by non-technical business users easier to manage. Does anyone else have any intuitions or experiences they could share on this, please? Thank you!

Hello,

I'm trying to implement a solution for this situation:

There is a restaurant in which users can access RestAPI, using Google, Facebook, GitHub. There is even the possibility to login inside using the SPID authentication. In the first case I was considering Keycloak as a better solution for this case, but then i've read about Okta and its pros.

I cannot understand reading and searching on Google if SPID authentication is supported by OKTA. Looks like to be, because it should be using SAML, but I haven't found a clear solution.

As the access to our global REST-API "Charon" is bound to OAuth2, we use Keycloak inside Quarkus to authenticate and authorize users of our API. It is not possible to perform any un-authenticated requests against this API, so we wanted to make really sure that the authentication/authorization component is absolutely reliable and tested. We found those attributes within Keycloak, so we used it.

I'm starting a new React Native project and trying to decide on an auth provider. Currently looking at Auth0 and Amazon Cognito. It will need to play nice with a Django Rest Framework backend.

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

Hey all, We're currently weighing up the pros & cons of using Firebase Authentication vs something more OTB like Auth0 or Okta to manage end-user access management for a consumer digital content product. From what I understand so far, Something like Firebase Auth would require more dev effort but is likely to cost less overall, whereas OTB, you have a UI-based console which makes config by non-technical business users easier to manage. Does anyone else have any intuitions or experiences they could share on this, please? Thank you!

We use OmniAuth with Devise to authenticate users via Twitter, GitHub, Bitbucket and Gitlab. Adding a new OmniAuth authentication provider is basically as easy as adding a new Ruby gem!

The only drawback I could see is that your OmniAuth+Devise OmniauthCallbacksController redirection logic can easily get hairy over time. So you have to be vigilant to keep it in check.