I am serving the react application through Apache. For SSO (Single Sign On) , I am using Apache based authentication. So the flow is whenever a user hitting the application URL , Apache will take care of getting the user information from SSO server and then it will redirect to home page. now I am having user information's in Apache response headers. Is there a way we can access these information in react js.
Note : I am not using any middleware application layer. Only React Js application.
Related
I've tried using JWT to my first SPA project (using Angular). In there, I store the JWT returned after login to localstorage. I was able to access it and pass as authorization header to every request.
Now that I have a NodeJS app serving the api and html/css/js how can I properly store it to the client to preserve his session?
I'm currently working on an odd project scenario. I currently have 2 servers, server A is used for authentication/sessions and to serve up multiple React applications, server B is simply an API for sending and retrieving data.
I have a javascript application that is walled behind a login screen so you can't access the app (and scripts aren't even loaded in) until after you authenticate via the server.
I need a way to authenticate via server A with a non javascript application, then after login, render the javascript application and pass the JWT to it to then be used for all future requests that are sent to server B. I also need to store a session on server A, so when the user refreshes the page, they still have access to the javascript application and don't have to login again.
The main thing I'm confused on is the proper way of handling this so users can refresh the page and still have access to the app, while also being able to have the JWT to make requests to the other server.
Let's use this picture as a demo
So I have 2 node apps. One is where I have the login pages etc., and 2 is the API server with JWT as security layer.
Currently, the first server is only for rendering client pages. I have a login page, and the route where the login process goes is in the server with JWT.
My problem is that I want to check my token if it's valid before rendering the login page. So I must do that in the first server.
What is the proper way of doing this? Can I install express session in my first server to store the token from the second server? In that way, I can send a request from the first server to the API server before rendering client pages.
I have two applications. First is MVC application, second is node.js application. MVC uses IdentityServer3 for authentication. I want to do screenshoots of MVC pages from node.js. I have phantom.js for this purpose. How to get token in node.js application without user? I want to open phantom.js with that token in header. I think it's possible. Node.js works as service and must make screenshoots every hour:)
client credentials flow is user less and serves your needs.
I have two Azure AD applications in the same directory, let’s call them FrontendAuth and BackendAuth, which provide authentication for an ASP.NET MVC frontend and a Web API backend, respectively. The MVC frontend is protected using the standard UseOpenIdConnectAuthentication configuration, the Web API backend with UseWindowsAzureActiveDirectoryBearerAuthentication.
What I want to do is log into the frontend, authenticate against FrontendAuth, then consume via JavaScript the API hosted in the backend by providing a token, acquired using ADAL JS, to BackendAuth.
Assumptions
My expectations/assumptions are:
That I would have to configure FrontendAuth to have access to BackendAuth in the classic portal
That I would have to edit the manifest files of one or both of these to set oauth2AllowImplicitFlow to true
That when I configure ADAL JS I should be setting clientId to be that of FrontendAuth
The endpoints object of the ADAL JS configuration should contain the Url of the backend API and the client ID of BackendAuth
Outcome
I can achieve my goal of logging in to the frontend and communicating with the backend service via ADAL JS with:
The FrontendAuth application having no access to BackendAuth at all
Neither manifest file having the oauth2AllowImplicitFlow property set to true
ADAL JS having the clientId set to be that of BackendAuth
The endpoints object of the ADAL JS configuration not set at all
Questions
Based on these findings I would like to understand the following:
Were my assumptions correct? Is this how ADAL JS is intended to work?
Why did the lack of application access and unchanged manifest files have no effect on whether the authentication succeeded?
When do these measures have an effect on the authentication outcome?
You are mixing up two OAuth2 flows here (authorization code flow and implicit flow). Both are meant to issue a token to a client application. The auth code flow is used for web apps running on the server (like your MVC app) and the implicit flow is meant for public clients like a SPA.
When you use OpenID Connect to sign in your user to your MVC application, using the hybrid flow, you receive an authorization code from the browser. You use this code to talk to the authorization server and get a JWT token which is then stored in a cookie session. You can use the same code to get a JWT token for your BackendAuth app, as long as you have given permission to your FrontendAuth app to call the BackendAuth app.
If you want to enable the JavaScript in the user's browser to call into the BackendAuth app, you'll need to somehow pass the access token to the browser. You can do this by sending the token along with the initial request and put it in local storage or expose a (secured) MVC route to get the token.
For an example of what I'm describing here see this Azure AD sample, which acquires a token for the Graph API using the authorization code is received.
ADAL.js implements the implicit flow and is meant for JavaScript applications like SPAs etc.
It sounds like you haven't explicitly decorated your Web API controllers with [Authorize] attributes (either at the class level, or the action level). Thus, your Web API may be happy to serve content to anyone who requests it.