For security purposes Service api uses SuppressDefaultHostAuthentication. If you want to use the standard configuration you will need to use headers for authorization and not cookies.  You can use the token endpoint setup on the service api or create your own authorization attribute which authorizes through the header.  If you dont want to use you need to change the standard configuration you need to disable which opens you up to csrf attacks.

Create a initialization module with dependency to EPiServer.ServiceApi.IntegrationInitialization

var handler = GlobalConfiguration.Configuration.MessageHandlers.FirstOrDefault(x => x.GetType() == typeof(PassiveAuthenticationMessageHandler));
            GlobalConfiguration.Configuration.MessageHandlers.Remove(handler);

SuppressDefaultHostAuthentication

While the MVC templates use a cookie based authentication mechanism, the new SPA templates prefer to use a token based authentication model explicitly passed via the Authorization HTTP header (which is better since it avoids CSRF attacks). This means that the default authentication from the host must be ignored since the authentication will be performed against something else other than a cookie. Web API 2 added a feature to ignore the host level authentication called SuppressDefaultHostAuthentication. This is an extension method on the HttpConfiguration that adds a message handler. The purpose of this message handler is to simply (and explicitly) assign an anonymous principal to the RequestContext’s Principal property. This way if cookie middleware does process an incoming cookie, by the time the call arrives at Web API the caller will be treated as anonymous.

Source: https://brockallen.com/2013/10/27/host-authentication-and-web-api-with-owin-and-active-vs-passive-authentication-middleware/

Thanks, Mark. Much appreciated. 

I wish the documentation/release info was a bit more candid regarding potentially breaking changes like this - I read the blog about the permissions-change and the AuthorizePermission attribute, but it really wasn't clear to me that this would break our WebAPI-auth.