Develop Reference

Cors and preflight errors with axios in vue

In my application I have got laravel as backend, jwt-auth as authentication, socialite as oauth2 provider and vue as my frontend.
Now I use axios to authorize the user by github for example (https://github.com/login/oauth/authorize) inside the client and then get the access token by the backend api.
If I do the authorize request with POSTMAN everything works, but if I do the request with my frontend axio request I get always errors. I think I get them because some Header values which are not correct. Can someone explain me which variables an axion request needs to perform an authorization request.
Kind Regards.

you can either disable cors in your browser which is very bad or you have to enable cors in your backend and to check if cors is enabled in your backend look for Access-Control-Allow-Origin header in browser network tab or you have to use proxy so that the requests are made to the same origin as seen by the browser but are redirected to some other url.
In create-react-app this works by adding
"proxy":"http://youUrl:portNo."

NodeJs Passport performs CORS pre-flight if request comes from VueJS

I am writing a NodeJS / Express backend that uses Passport with the Saml-Stategy. I am using an external Identity Provider and VueJs as a frontend.
If I do an API request to the backend from the browser (Chrome + IE) everything works fine. The request goes to the backend, goes to the IdP as GET request and comes back authenticated.
But if I load the VueJs app that does the same request, passport makes a CORS pre-flight (OPTIONS) request that comes back from the IdP as 404, because OPTIONS is not supported. I tried Vue-Resource and Axios, both the same result.
Unfortunately I can not change any settings on the IdP. But why does my passport in the backend treats the requests differently? Any Ideas?
I compared the request headers from the API call and VueJs, and I cant find any headers that would cause the pre-flight.
Repository: https://github.com/tmschbgr/NodePassportExample
Versions:
Node: 8.9.0
Express: 4.16.2
Passport: ^0.4.0
Passport-saml: ^0.31.0
Vue: ^2.4.4
Axios: ^0.17.1

I found out that it was causing due to a timing issue.
It works with the following logic:
Request comes to Backend, check if authenticated
If not, go to IdP and come back. If successful redirect to /
Serve the static file AFTER the authentication check. That way the app only gets served when the user is authenticated.

Authenticating with ADAL JS not behaving as expected

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.

What is the correct CORS entry for limiting an http:// connection to a remote, hosted web server from a grunt web server on a home network?

I've setup a remote, hosted javascript server (DreamFactory Server http://www.dreamfactory.com/) that responds via REST API's.
Locally, I'm running an Angularjs application through the grunt web server via $grunt serve
https://www.npmjs.com/package/grunt-serve
I have setup CORS on the remote server to allow '*' for multiple http:// connection types. THIS WORKS CORRECTLY.
My question is how I can limit the CORS configuration to only allow a connection from my home, grunt web server?
I've tried to create an entry for "localhost", "127.0.0.1", also my home Internet IP that is reported from whatismyip.com, the dns entry that my provider lists for my home IP when I ping it, a dyndns entry that I create for my home internet IP... None of them work, except for '*' (which allows any site to connect).
I think it is an educational issue for me to understand what that CORS entry should look like to allow ONLY a connection from my home web server.
Is this possible? If so, what and where should I be checking in order to find the correct entry to clear in the CORS configuration?
-Brian

To work and actually apply restrictions, the client requesting the connection must support and enforce CORS. In an odd sort of way (from a security point of view), restricting access using CORS requires a self-policing client (one that follows the prescribed access rules). This works for modern browsers as they all follow the rules so it generally works for applications that are served through a browser.
But, CORS access restrictions do not prevent other types of clients (such as any random script in any language) from accessing your API.
In other words, CORS is really about access rules from web pages that are enforced by the local browser. It doesn't sound like your grunt/angular code would necessarily be something that implements and enforces CORS.
If you really want to prevent other systems from accessing your DreamFactory Server, then you will need to implement some server-side access restrictions in the API server itself.
If you just have one client accessing it and that client is using "protected" code that is not public, then you could just implement a password or some sort of logon credentials and your one client would be the only client that would have the logon credentials.
If the access is always from one particular fixed IP address, you could refuse connections on your server from any IP address that was not in a config file you maintained.

You can't secure an API with CORS, for that you will need to implement an authentication scheme on your server. There's essentially 4 steps to do this.
Update the headers your server sends with a few additional Access-control statements.
Tell Angular to allow cross-domain requests.
Pass credentials in your API calls from Angular.
Implement an HTTP Authentication scheme on your web server or in your API code.
This post by Georgi Naumov is a good place to look for details of an implementation in Angular and PHP.
AngularJS $http, CORS and http authentication

Authenticate client-side app to REST API using CORS with local strategy

The Problem:
Serving a secure API to a client side app using only a local authentication strategy. The red arrows are part of the knowledge gap.
Context:
That is --- client.example.com is making a POST to api.example.com/login where on success client.example.com can gain access to a GET service like api.example.com/secret.
An idea!
Implimentation of OAuth 2.0 with hybrid grant type sitting in front of API.
Why hybrid?
It wouldn't be an Implicit Grant Flow aka Client-Side Web Applications Flow because there is no redirection to API server too grant access token. (i.e.) "Is it ok for so-and-so to access your data?"
It wouldn't be a Resource Owner Password Flow because a Client ID and Client Secret are passed along with the request so it's assumed the client app is server-side.
OK... so what about a little bit of both?
What if we used a CRSF token on page load of client-side app, and POST it with user credentials too OAuth 2.0 authentication endpoint to exchange for access token? You would authenticate each subsequent request with the access token and CRSF token after a successful login.
A good Node.js OAuth 2.0 library I found:
https://github.com/ammmir/node-oauth2-provider
Help Me!
I can not find a working example of an authentication measure that solves this problem! Point me in the right direction?
Ultimately, the goal here is too authenticate a client side app to a REST api using CORS with a local strategy --- i.e. username & password --- even if the convention above isn't possible.
To Accommodate Bounty:
This is a client side app, so let's stay trendy.
I'm looking for a working example using the Node.js OAuth 2.0 seed above for the API/Auth server and a front end framework like Angular.js or Backbone.js to make requests.
The example should match the context described above.

I'm working on an app with a pretty similar architecture though the services are .NET Web API rather than Node and we're using DotNetOpenAuth for the OAuth provider. Rather than the hybrid approach you're suggesting we're doing the following:
x.com serves up a login page
login page POSTs back credentials to x.com
server side logic at x.com combines client_id and client_secret with the credentials to submit a token request (resource owner password credentials grant that you've
mentioned above) receiving back both a temporary access token and a
refresh token
the refresh token is encrypted into a cookie issued by x.com
both the cookie (with encrypted refresh token) and the temporary access token are then sent to the browser
the client app (angular in my case) can now use the access token to hit api.x.com for services (It appears you're well aware of the limitations of CORS... we hacked a version of angular's $resource to facilitate this but it wasn't pretty since we wanted to use all HTTP verbs and support IE9)
when the access token expires, the client side app can request a new access token from x.com
server-side, x.com decrypts the cookie to get at the refresh token and issues another oauth call for a new access token
This is fairly high-level but hopefully gives you a sense for how to tackle your situation. In my case, and it appears in yours, we didn't want to use session state or a database to store the refresh token but obviously exposing that to the browser introduces security concerns so the encryption of the refresh token is important (among other security considerations) and the use of the cookie eliminates the need for session state or other persistent storage on x.com.

Not an answer running for the prize. Just my 2 cents :)
On my web server,
I do my authentication through a rest call with login/password with basic authentication over https. This call delivers a key to the client (a one page web app).
Then every subsequent REST call is signed with the key. The server checks that the signature is correct and everything still happen in https.
This mechanism is quite used I believe.
I don't see the issue with cross domain. I have a single source anf if I need something from another source, I'd use JSONP.
I use nginx as an https->http forwarder.
Not sure how it competes with an OAuth2 solution.

I've built this example using Node and PassportJS to show how to authenticate the users with Facebook or Local Strategy. Both sides are on different domains as you described and it requires CORS enabled.
GitHub: https://github.com/pablodenadai/Corsnection
Live demo: http://corsnection-client.herokuapp.com/

I can't promise that I have time to write working example but I can show you 2 paths :)
The biggest deal is CORS. After you solve that problem it is easy to use $http service. So, first and probably easiest may be to configure reverse proxy in x.com webserver which points to api.x.com. I wrote article here
Second approach is better, and created for exactly this purpose, to authorise specific domain to use your resource. It involves a bit of coding in api.x.com so you don't have to change anything in new web applications served in other domains. You simply need to authorise CORS requests in api.x.com service.
Create table in database where you can manage list of authorised domains
Add in that table record "x.com"
in api.x.com add request filter/interceptor what ever tech term you use for method which should be invoked after request is handled and add in response Access-Control-Allow-Origin: x.com if request comes from x.com (in other words check in request header refer value match to any value in table above and put that value in Access-Control-Allow-Origin response header).
That is all :) After this if you know how to use $http or jQuey.ajax you will be able to POST/PUT/DELETE/... any request to api.x.com from any authorised domain in just few minutes.

I very similar idea using vinilla js web app and cross domain authentication to GAE backend or OpenID connect.
The web app is run on CDN. When click login link, it goes to respective login server and redirect back to the web app (with XSRF security token and HTTPS only cookie). Login server accept cross domain request with credentials. XSRF token has to be set (in header) with every request. cookie is set by the browser. Since it is HTTP only cookie, JS cannot read it. The technique is very secure.
Once login, you can get secure assess from login server.
For detail description, you can find here and open source repo here.