I am currently programming a Nuxt app for my company. My problem now is that this app requires user authentication with at least credentials. The best I've found is Auth0. But my problem is that I can't/may not use any external services that require an account. I currently have my own backend right in the Nuxt app for all data that works with Prisma as the ORM. I'm currently using Sidebase's Nuxt-Auth. But for me it's not the optimal choice because it doesn't really support 2FA for the credential provider and I can't have an error in the login form, for example (so, for example, if the password is wrong, it will be displayed under the input). What is the best way in my case? Here are my requirements.
Credential Auth with 2FA
No additional software I need to run (like supabase)
No external service
You pretty much found the solution yourself already.
The nuxt module is having too much abstraction, hence it's not flexible enough for your use case.
Auth0 may be a better fit, especially if you use it as is (with just the JS part of it).
Want even more flexibility? You will need to code something yourself, never served best than yourself.
Depending on your requirements, time, and knowledge, you may pick 1, 2, or 3 above.
No magic solution baked-in into Nuxt per se. It's also a JS meta-framework so you will likely have to manage the auth part via some network exchanges etc...in comparison to a Laravel, Ruby on Rails app for example.
Related
I'm currently working on a project where we are using OpenID Connect and Oauth2 with Keycloak's default forms.
We have requirements to implement 2FA. In an ideal world we'd scrap the keycloak forms all together and just use keycloak as a headless API and build the login forms in the main application itself.
The reasons being
We have components built in Vue.js we would like to re-use (e.g. password/code inputs, password strength indicator etc)
We don't want to maintain the same styles in two different projects
We don't want to maintain or be limited by custom templates
Don't want to write custom behaviour in vanilla js
After doing research I've found that using keycloak as an API is not recommended because the redirection between the client and 3rd party login acts as an additional layer of security, and is part of the OAuth2.0 model. We're storing users medical information so security is a concern.
What would you guys suggest?
You are right that using an OAuth server through an API is not recommended. Redirects are an important part of the security of an OAuth flow. This of course creates all the drawbacks that you mentioned - having to maintain multiple codebases with the same functionality.
A solution to this problem is to use hypermedia API with strong security mechanisms, which can be used to perform OAuth flows. Unfortunately this is not a standard yet, and it is an emerging feature. You can read how such an API works here and here you can find an in-depth description of the security features of an implementation we did at Curity.
It will definitely not be an easy task to implement it in Keycloak currently, but there most probably there is no other option to solve this problem - as you said you need 2FA, without 2FA an option is to use the Resource Owner Password Flow.
I am using Nuxt (with SSR/ PWA/ Vuejs/ Node.js/ Vuex/ Firestore) and would like to have a general idea or have an example for the following:
How can I secure an API key. For example to call MailChimp API
I am not familiar with how a hacker would see this if a poor solution is implemented. How can I verify it is not accessible to them?
I have found a number of "solutions" that recommend using environment Variables, but for every solution someone indicates it wont be secure. See:
https://github.com/nuxt-community/dotenv-module/issues/7
https://github.com/nuxt/nuxt.js/issues/2033
Perhaps server middleware is the answer? https://blog.lichter.io/posts/sending-emails-through-nuxtjs and https://www.youtube.com/watch?v=j-3RwvWZoaU (#11:30). I just need to add an email to a mail chimp account once entered, seems like a lot of overhead.
Also I see I store my Firestore api key as an environment variable already. Is this secure? When I open chrome dev tools-> sources-> page-> app.js i can see the api key right there (only tested in dev mode)!
You could use either a server middleware or https://github.com/nuxt-community/separate-env-module
Middleware itself wont work because it can be executed on client too, and code that is used in middleware will be available on client
For #2 you can check whether its included in client js sources. There way more other way hacker to get anything e.g. xss, but its general things and not much related to your code.
How can I secure an API key. For example to call MailChimp API
The cruel truth here is NO... In the client side you cannot secure any kind of secret, at least in a web app.
Just for you to have an idea of the techniques that can be used to protect an API and how they can be bypassed you can read this series of articles. While it is in the context of an Api serving a mobile app, the majority of it also applies for an API serving a web app. You will learn how api-keys, ouath tokens, hmac and certificate pinning can be used and bypassed.
Access to third part services must be always done in the back-end, never on the client side. With this approach you only have one place to protected, that is under your control.
For example in your case of accessing the Mailchimp API... If your back-end is the one in charge of doing it in behalf of your web app, then you can put security measures in place to detect and mitigate the usage of Mailchimp by your web app, like a User Behaviour Analytics (UBA) solution, but leaving for the web app the access to the Mailchimp API means that you only know that someone is abusing it when Mailchimp alerts your or you see it in their dashboards.
I am not familiar with how a hacker would see this if a poor solution is implemented. How can I verify it is not accessible to them?
As you may already know F12 to access the developers tools is one of the ways.
Another ways id to use the OWASP security tool Zed Attack Proxy (ZAP) , and using their words:
The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers*. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. Its also a great tool for experienced pentesters to use for manual security testing.
Storing secrets in the front-end is a big no no in terms of security.
If your website is using server-side rendering (aka SSG or static website) and is hosted on Netlify it sound like a perfect job for the Netlify functions (server side logic) and environnement variables.
You can find some documentations here : Netlify functions.
Netlify functions are powered by AWS Lambda.
You would typically create a function folder into your project directory and write your functions there. Functions are built after each deploy but you can test your functions locally with Netlify Dev
Here is an example of function using Mailchimp service wit injected secrets :
https://github.com/tobilg/netlify-functions-landingpage/blob/169de175d04b165b5d4801b09cb250cd9a740da5/src/lambda/signup.js
I think privateRuntimeConfig, by which secrets are only available on the server side is another workable solution here, if you're in a situation where you only need to access an API during Server Side Rendering.
https://nuxtjs.org/tutorials/moving-from-nuxtjs-dotenv-to-runtime-config/#misconceptions:~:text=privateRuntimeConfig%20should%20hold%20all%20env%20variables%20that%20are%20private%20and%20that%20should%20not%20be%20exposed%20on%20the%20frontend.%20This%20could%20include%20a%20reference%20to%20your%20API%20secret%20tokens%20for%20example.
Parse? Auth0? Firebase? Ionic Platform?
I'm so lost... Can anyone help me?
If you are looking for a "backend in a box" then If you are creating an API meant to be consumed by an Ionic application, JWT is probably what you are looking for. Parse, Auth0 etc may help. I have not used them. However, if you are building your own backend it will be dependent on what server side framework you are using. It's safe to say that JWT is a good approach on the client side(angular/ionic), but you will need a serverside authentication and account system such as Passport for Node, Devise for Rails etc.. Either of those will handle basic authentication and account management. You will need a JWT layer as well to produce and manage tokens for the client. You can also create a homebrew system if you choose to but the frameworks I mentioned make things quite a bit easier.
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.
I am developing a google chrome extension that needs to communicate with a nodejs server. I was wondering if its possible to use everyauth package to simplify authentication. For starters, I just wanted to use simple password based authentication. But from the examples and the documentation ,as well according to my trial, it seems to me that everyauth is designed to be used for a webapp and gives me errors if i don't set the getLoginPath. Also i am not sure how to configure everyauth to send the user details or errors after user authenticate in a json payroll rather than redirecting user to a particular page. This is my first project with node.js and I am looking for some advice on how to go forward with this. I am open to using some other package/library that provides such authentication,
Since you are open to using other modules, as the developer of Passport, I'd suggest you look at it: https://github.com/jaredhanson/passport
Passport is designed to be a simple and unobtrusive authentication library, which makes it easy to get up and running quickly. It's also modular and extensible, which allows it to adapt to your applications needs over time.
The examples provided, along with the local strategy ( https://github.com/jaredhanson/passport-local ) are enough to get you started with username/password authentication. Let me know if you have any feedback or questions.
I was able to accomplish a REST-only interface to everyauth by overriding its handler methods: https://gist.github.com/2938492