I have front end - x.sameDomain.io.
and a back-end y.sameDomain.io. It basically I use for signup/signin and some other basic queries and this backens sends a http only cookie to the front-end.
Recently I have created another bakc-end z.sameDomain.io in aws lambda. Now the problem is whenever a user sends a request to y.sameDomain.io the cookie authenticates the user. But since there is a new backend z.sameDomain.io, now I am confused how I may authenticate users in z.sameDomain.io.
Is there a way I can login using y.sameDomain.io but both the back-end will recognize me?
I am new to this multi back-end system and not sure how resolve this issue?
Related
I have an app which consists of frontend server and a backend server.
front end server connect to corporate OKTA mechanism so that user logins through their corporate ids into my app.
After this step, frontend server connects with some backend work at backkend server (node js). Their it passes in the request body the user id so that we can finally log that the below processing is happening due to user X.
Now suppose user A logs into the app . Now during the APi call to backend server, he can modify the arguments being passed to the api and somehow change the userID.
Is there some way by which backend server validate that userID is not compromised ?
Regards
If your front-end app uses OIDC to log a user in, then you should be able to get back an id_token, which has user identity in it. You can pass this token to your back end app for API calls. This approach is not ideal though, as your backend will still have issues with trust, as it does not know if the token presented by the front-end app is a legitimate one and not stolen.
Other way is to harness traditional authorization_code flow (again, assuming you can do OIDC with you company's identity provider). There your back-end would retrieve the tokens for you directly from authorization server and can get a user's identity from it. Based on that it can then create a session and embed user info into it. It's a bullet proof approach lacking trust issues from above.
I’m having trouble figuring out how to get Node.js backend tokens into React.js frontend local storage. To login a user will use their credentials though an external websites API using the Oauth2 flow, this will be the only way to login into the application.
Currently, the user clicks a button which opens a new window in the authorization URL where the user will grant privilege. Once granted, the user is redirected to the backend endpoint which goes through passport.js and gets the required access and refresh tokens sent from the external API. This is then stored in a session on the backend database. What I want, instead, is to not store a session on a database but instead implement JWT and store the user’s data in local storage. With the current flow, its just not possible to do this and I haven’t found the right documentation to work it out.
There are many websites that implement it the exact way I want but tracking down the way they do it has appeared to be a challenge in on itself.
So instead of using passport.js, which was causing a plethora of issues, I decided to implement the Oauth2 flow myself. Instead of doing ALL the work in the backend, I broke the flow into different parts.
Originally, I sent the user to the backend where they would recieve an authorization token there. This turned out to be troublesome, instead, request an authorization code on the front end. For example, send the user to the Auth path and redirect the user back the the front end once privileges have been granted. Wait at the frontend callback for a code, once obtained, send a post request to the backend with that code and any other data in the body.
When obtained at the backend, trade that code for the access token and respond to the post requst with the neccassary token and any other data that needs to be sent back e.g. profile name, picture, date of birth. You can the implementn the JWT flow and no database is required to store any session or tokens, all can be stored client side securely.
I've been studying the OAuth 2.0 authorization code flow and am trying to write a React application with an Express backend that displays what a user would see on their own Instagram profile. I'm trying to do so with minimal external libraries (i.e. not using passport-js) and without bringing a database into the mix.
This is my flow as of now:
Resource owner clicks an <a> tag on the React application (port 3000) which redirects them to the /auth/instagram endpoint of my Express server (port 8000)
res.redirect(AUTHORIZATON_URL) sends them to Instagram's authorization server
Resource owner consents and the authorization code is sent back to the predefined redirect-url /auth/instagram/callback with the authorization code set as a query parameter
I strip the authorization code off the url and make a POST request to https://api.instagram.com/oauth/access_token to grab the access token
Now that I have the access token, how do I reach out to the React frontend to let them know that everything worked and that the user was successfully authenticated?
From what I've read, this is where the idea of sessions and cookies come into play, but I haven't had luck finding documentation on how to achieve what I want without bringing in third party libraries.
In the end, I would like for my app to support multiple users viewing their profiles simultaneously. Since I imagine passing the access token to the frontend defeats the purpose of securely retrieving it on the backend, I'm guessing I will somehow need to pass a session id between the frontend and backend that is somehow linked to an access token.
Any ideas as to what my next steps should be are greatly appreciated, as well as any articles or documentation you see fit. Thanks!
Since you're doing the OAuth authentication on the server side, you have to pass some parameter to the redirect_uri, identifying the user session (see: Adding a query parameter to the Instagram auth redirect_uri doesn't work? );
When the redirect uri is called from the authority server, you will know which user was authorized. To notify the browser there are two options: 1) Notify the client using web sockets; 2) Pull the state from the client using a timer triggered function;
I have created an angular 2 application. Now, these are the requirements for windows authentication.
1) If any user within the organization access this application, he should not get the login prompt and should be able to login directly into the application.
2) If any specific user within the organization tries to access the application, then he should get the specific role(Like admin, Manager) and able to login directly.
3) If any user outside the organization tries to access the application, he should get the login prompt.
Edit: Backend will also play the significant role. I have created rest API using node js and express. So will this passport package help in my case? I have implemented the passport.js on my node js rest API, but now how to validate that thing on the angular side.
Any help will be appreciated and bounty awarded.
For this to work the back-end will be your primary point of call, passport.js (Implemented in your node.js not your client) will allow you to do a lot of the heavy lifting but will still require some fundamental changes to your web server.
You are looking to implement IWA (Integrated Windows Authentication) here, if you wish your client to know which roles the user has the way I would suggest would be to create a API on the server side that returns these variables as part of its response (then take them and store them somewhere for your angular2 to use).
For example you could have /authCheck return { role: [], username: "Username" } and if the user is not authenticated return a 401. This way if the passthrough IWA fails you can handle the 401 response by directing a user to the login page.
I am trying to create an application with the following requirements.
Login page for entire application that authenticates against AD
(currently using passport-activedirectory)
This also needs to authenticate against a jira api for the user to create tickets through my application. Should this be done at
initial auth or once the route is hit to send the request to jira?
It's possible that other api's will need to be authenticated against.
I'm trying to figure out the best way/standard way to do this so the user will only have to authenticate through my web application once.
Any direction is appreciated.
Thanks