How can I have one web service provide a front-end authorization process (login form, Facebook login, Google login, etc.) for a second NodeJS application?
Scenario:
WEB APPLICATION # www.first_domain.com
- Hosted in IIS
- Provides a web service with OAuth support
- Web-based login form
NODE.JS APPLICATION # www.second_domain.com
- Hosted on Heroku
- Node.JS handles all api / web service calls
- AngularJS app must only call this server
I know the web application has the ability to take a URL as the return path, once a login is complete, and send the user back to the site via the browser. However, I've been told to NOT allow the Angular application to communicate with the other web application directly... IF there is another way (basically using the NodeJS application like a proxy).
Another concern I have is how to maintain the session token from the other web application. The NodeJS application has the responsibility to use the other application and web service to ensure the session remains valid.
Related
Components:
HTML, Bootstrap, AJAX Single Page Application (SPA) --> Deployed on-premise on tomcat 1
Azure Application Proxy 1 fronting SPA with pre-authentication as passthrough
REST API (API) --> Deployed on-premise on tomcat 2
Azure Application Proxy 2 fronting API with pre-authentication as Azure Active Directory
Microsoft MSAL Javascript library: https://github.com/AzureAD/microsoft-authentication-library-for-js
Flow:
User accesses SPA using Application Proxy 1 external URL eg. https://appProxy1.com/spa
The SPA has a sign-in button, when clicked invokes the Microsoft js MSAL library.
The user is presented a pop-up and upon entering credentials, is authenticated against Azure AD and an OAuth token is fetched.
Once authenticated successfully, the user is allowed to perform search on the SPA.
When the user searches, the SPA invokes the REST API using the application proxy 2 url eg. https://appProxy2.com/rest/.search
The REST call is blocked by browser due to CORS. It seems that Application Proxy/Azure AD is not allowing cross origin calls.
Note:
CORS has been enabled in the REST API code and SPA is able to invoke the REST API if Application Proxy 2 pre-authentication mode is set as passthrough.
I have gone through https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-understand-cors-issues. This workaround is possible if HTML application and REST service are deployed on the same application server.
Question:
Is there any option to enable/configure CORS on Application Proxy.
Currently there is no way to configure/enable the CORS on Application Proxy.
There a user voice request for CORS App Proxy. Please feel free to up vote this user voice request.
I've just uploaded my first app on Azure: it is a .net core MVC site + webapi + sql server. This app will be used by one user.
How can I limit the access to the app using a login, without developing that part on .net core?
One service you could use for this is App Service Authentication.
Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions.
If the user is from a specific location, you could also look into how you can configure Azure App Service Access Restrictions.
I am working on a webapp, the Front-end is implemented in AngularJS which talks to back-end server by invoking REST API. The back-end is Java REST Server implemented using reslet framework deployed in Jetty.
Currently, when a user logs into a web app, a REST API is invoked which then goes to the Java REST server. The server then authenticates the user.
I want to implement SSO using SAML. So when a corporate user tries to login to the app, the user must be redirected to ADFS. If the user is successfully authenticated he must be allowed to login to the app.
I want to know how do I start? I have seen sam2-js library, however it seems to be for NodeJS based server. I am not quite sure if it can be used with AngularJS on frontend.
SSO with SAML involves browser redirects so the flow is between angular and ADFS.
There's no Java backend.
So Jetty is irrelevant.
SSO has nothing to do with REST. They are two different flows handled in two different ways.
SAML is not a suitable SSO protocol for angular. That's why you can't find any examples.
You need to use OpenID Connect with ADFS 4.0. ADAL is the way to go.
I have an angular web app talking to a c# .net web api back end.
They are both hosted on azure app services.
Azure app services offers a suite of authentication services and I've chosen to use google auth.
I've got my google client id and secret setup in azure google auth and my web app correctly shows and prompts me for my google credentials.
My problem now, is that i need my web api back end to authenticate the web app google token. I couldn't find any articles or tutorials that demonstrates the following:
How to get and send the token to the web api? I've read that azure app service should automatically inject the necessary auth headers but any calls to my api do not include those headers. Should i manually call auth/me and add them to the request header?
How do i get my web api to authenticate the details from the request header with google auth? Do i need a separate client id for the web api or should i re-use the web app client id?
Cheers!
According to your description, I assumed that you are using the built-in Authentication / Authorization provided by Azure App Service.
AFAIK, App Service Authentication (Easy Auth) provides two flows: client-managed and server-managed flow. For the server-managed flow, the server code manages the sign-in process for you, and your backend would directly receive the token from the relevant identity provider (e.g. Google, AAD,etc.), then both generate a authenticationToken for browser-less apps and AppServiceAuthSession cookie for browser apps. Details you could follow Authentication flow.
For your angular web app, you could just use server-managed flow, after user successfully logged, you need to call https://<your-angular-app-name>.azurewebsites.net/.auth/me to retrieve the google access_token, then send the following request against your web api endpoint for retrieving the authenticationToken as follows:
POST https://<your-webapi-app-name>.azurewebsites.net/.auth/login/google
Body {"access_token":"<the-google-access-token>"}
After successfully retrieved the authenticationToken from your Web API endpoint, you could send the following subsequent requests for accessing your APIs:
GET https://<your-webapi-app-name>.azurewebsites.net/api/values
Header x-zumo-auth:"<authenticationToken-generated-by-your-webapi>"
Moreover, you could also use client-managed flow in your angular web app, you may need to directly contact with your identity provider (Google) to retrieve the access_token in your client via Auth0 or google-signin or other third-party libraries. Then you may need to both send request to your angular web app and Web API web app for retrieving the authenticationToken as the above request sample.
Do i need a separate client id for the web api or should i re-use the web app client id?
Per my understanding, you must use the same google application. For AAD authentication, you could configure a AAD app with the access permissions to another AAD app.
We are designing a web site for selling financial products online.
The following is a high level description of the components:
Our frontend will be a SPA built with AngularJs.
The frontend will communicate with an API hosted in Heroku.
The API will expose web resources which allows the execution of the
business process.
The API hosted in Heroku serve as a passthrough between the frontend
and the real services which actually do the tasks.
The purchase process is designen to not ask for user/password or
account creation at any point.
We have some queries we execute thru the API which returns confidential information -confidential according to the local law-
We want the frontend to authenticate to the API to retrieve this information still NOT asking for credentials to the user.
We thought about a local persistence of the credentials and obfuscating the request but that would be easy to break with a proxy so the request can be read clearly.
What would be an option for this need of authenticating the frontend without asking for credentials to our clients?