Unauthorized on valid JWT in nodejs - node.js

I'm developing an nodejs app, I already handle a register, login and profile api which work perfectly.
I am using passport-jwt to generate a valid JWT to access the user profile.
The first version of my app is monolithic.
I wanted to switch on docker microservices architecture for my app.
I succeeded on separate register, login and profile into 3 separate containers. My register and login microservices are working great.
The only problem is that the JWT that is generated by register or login services seems to be invalid (Unauthorized on profile api) but it wasn't the case when my app was monolithic.
I didn't change my code.
Did anyone experienced that issue ? Am I missing something ?

I believe this should be due to CORS because when you ran your app as a single monolith all the requests originated/served from the same domain name which is not the case when you split that into different services running in separate containers.
I had faced similar issues while trying to implement ldapauth-fork and solved it by setting explicitly the below http header -
res.setHeader('Access-Control-Allow-Origin', 'https://yourprofileservice');
Check on this and if you still face issues please do share the errors you receive on your end.

Related

Authenticating a Vue 2 Azure Static Web App Locally Against Auth0

I am researching the feasibility of porting an existing Vue 2 app to be an Azure Static Web App (SWA). A requirement is the ability to run the Vue app locally and authenticate against our Auth0 tenant to retrieve a access/bearer token to send along with our HTTP requests.
It appears that a SWA can utilize custom authentication (Auth0), and I was able to complete that successfully by following this article. However, I'm not seeing any information around capturing the access token. There is an /.auth/me/ endpoint which has user information, but that does not contain the access token:
I also looked into the Azure Static Web App Emulator which allows for defining an identity profile when running locally, but I'm not seeing a way to specify an access token here either.
Is it possible at the moment with a SWA to obtain an access token using a custom auth provider when running locally and when published live?
Managed Authentication in Azure is really only useful for fairly simple use cases. I think you're going to want to implement your security directly inside your Vue application.
https://auth0.com/docs/quickstart/spa/vuejs/01-login
You mentioned needing an access token but didn't say where it comes from or what you're doing with it. Are you trying to call an Auth0-secured API?
https://auth0.com/docs/quickstart/spa/vuejs/02-calling-an-api

How to setup OAuth2 connection to Google Identity API within an Electron app safely with redirectUri pointing to localhost?

The context:
I'm trying to develop a desktop app with ElectronJS which needs access to Google APIs. As such, I want my users to be able to connect to their Google account via OAuth2.
As I use Electron, I have no safe way to store a "client-secret" and must use the "mobile app" method.
The problem:
Google keeps rejecting my redirect_uri:
The doc I followed:
The official npm "google-auth-library" package mentions the following regarding OAuth authentication for Electron apps ("OAuth2 with Installed Apps (Electron)" section) :
If you're authenticating with OAuth2 from an installed application (like Electron), you may not want to embed your client_secret inside of the application sources. To work around this restriction, you can choose the iOS application type when creating your OAuth2 credentials in the Google Developers console
As doing so gave me the previously mentionned Error 400, I looked into Google Identity documentation and saw this regarding localhost redirection:
Note that support for the loopback IP address redirect option on mobile apps is DEPRECATED.
My question:
At this point, I suspect that this is the reason Google is responding Error 400 to my requests (but I admit it could be my fault. I just don't understand what I do wrong as I feel like I follow the documentation strictly.)
If so, what are the possible ways to solve the issue ? Knowing that I have strictly 0 budget for this project and so I cannot afford to redirect to a domain I would buy or afford a server acting as proxy between my app and Google APIs.
(The code, if useful)
I use the "complete OAuth2 example" from google-auth-library except I changed the OAuth2Client constructor call to this, following the doc's recommandations:
const oAuth2Client = new OAuth2Client({
clientId: "<the clientID of my project from Google API Console>",
redirectUri: "http://127.0.0.1:3000"
})
In despair, I've tried a whole lot of different URL formats, but nothing works.
Thanks in advance for your help.
OAUTH BEHAVIOUR
An OpenID Connect desktop app uses PKCE without a client secret. According to RFC8252 it then receives the login response on either a loopback URL or via a private URI scheme notification.
The loopback option is fine for a desktop app but should not be used for a mobile app. Conversely, claimed HTTPS redirect URLs work for mobile apps but not desktop apps.
TROUBLESHOOTING YOUR PROBLEM
It is not clear whether your problem is caused by using a loopback URL or something else. To troubleshoot, you can use a couple of demo Electron apps of mine:
Loopback example
Private URI Scheme example
In both cases, edit the desktop.config.json file in the root folder. Replace my AWS Cognito values with your Google values. Then run npm start. See if that gets you any further, and post any follow up questions.

How to implement Security in Rest API developed using Node.JS?

I want to design a SPA which will have Frontend (React) and Backend-Rest API (Node.js, Express, Mongo DB). I am planning to have Single Sign-On in my application where users would be authenticating using MS-Azure AD, where a call would go to Azure AD from Frontend and in return I will get a token for that User which will be stored locally. After that, I want to call my rest API, for multiple GET, POST, PUT operations in the context of current user logged in on UI. Planning to deploy both frontend and backend on different servers so here I have two questions about securing my REST API.
CORS Implementation
User-Authentication on BE
Given the above requirements is it enough to have just CORS implemented or Do I need to again authenticate the User on BE?
Can somebody provide some best practice or experiences? Is there a lack in my “architecture”?
While CORS is definitely a consideration, it isn't Authentication (AuthN) or Authorization (AuthZ) which you need.
Depending on the number of users your application will have, how the back end will scale you might want to look at OAuth2.0 or stick with simpler session based auth but you will need something.
CORS on your back end will limit if a browser running an app on a domain other than yours to call your web services (it wont stop API requests from other tools).
AuthN - Your not logged in - go get logged in and come back to
me.
AuthZ - Controls what your users can and cant do. You might want to
enforce this at the resource level but you absolutely need to within
your business logic.
Further reading https://auth0.com/docs/authorization/concepts/authz-and-authn
Philippe from Pramgmatic web security has a free online course to get you started: https://pragmaticwebsecurity.com/courses/introduction-oauth-oidc.html Its very well paced and should give you some foundational knowledge. (It might let you write off OAuth for this use case but give it a go)
CORS will not perform any user authentication. You need CORS only when your client code is served from another domain than the backend you are talking too. If it is the same server to host static client files and backends REST endpoint, you don't need CORS. If you are unsure, then don't consider CORS at all and see if it works.
But you need authentication to know which user is which.

socketcluster jwt auth using token generated on another server

(Tom Vaga asked a similar question here but Luke's response didn't quite address what I'd hoped to accomplish... I'd comment there but don't have the points yet :-) Thanks! )
I've got a Slim server working well to register and authenticate users for our API, using JWT, allowing only 'authenticated' users to access certain api endpoints.
I'm now trying to setup a SocketCluster for various realtime messaging parts of the app, and I would like to restrict subscriptions to only authenticated users. I may be missing a part of the concept, but is it not possible to use the token-cookie set successfully by Slim to also authenticate to SocketCluster? (ideally using the built-in authentication process, and without having to call-back to the slim-api?) They're on different servers as sub-domains... Would I have to insert the same secret into the SocketCluster configuration somewhere?
Thank you!

Share AccessToken between AngularFire2/Firebase and NodeJS

I feel like I am wanting to do something that is either easy, or very wrong. Not sure which one yet.
I am wanting to build an application that is backed by Firebase for:
Authentication
Realtime Database
I will build an Angular2 Front end Single Page App using AngularFire2. Using AngularFire2, the user will authenticate using GoogleAuthentication provider. The Angular2 app will interact with the firebase realtime database directly under most cases.
But I have some cases that I want a NodeJS/Express REST API layer todo more complex business logic and interact with FireBase Database. What I want to have happen is when the user authenticates with AngularFire2 that the accessToken can be used on the API calls to NodeJS in the HTTP Header. Then inside the NodeJS Firebase SDK I just authenticate using that token.
How would you go about doing this? I've been digging through documentation for a while now and still haven't figure it out.
Took lots of digging, but I found the solution. I hope this is a useful thread for others to find.
The accepted answer at: Answer gives a good lead to this. Specifically look at:
Authenticating your privileged workers
Emulating users or limiting access from a server process
Validating client identity via security

Resources