When I'm in charge, I typically model services separate from endpoints.  For example: Company.Project.Domain.dll has all of the logic required to complete the services for that domain.  In order to access it you either reference that library or, if I'm exposing the services through an endpoint, you can hit Company.Project.Endpoint at the URL: api.wutevz.com/blog/Message/I mention the above because I have (seemingly unfortunately, but maybe I'm the wrong one) seen the majority of services/domains created directly inside an endpoint project (like WCF or Web API).  And knowing my setup is key to my question.  Also, if separating the logic from the endpoint is weird, feel free to chime in.  While I think separating them is correct, I'm jaded from many years of consulting and seeing them joined.The question, if my methodology is sound, is: Where should Authentication Live in the backend?  This is unrelated to other questions asking if it should be in the backend vs the client.  My question is: On the Endpoints, or on the Services?So my Web API has this Endpoint:[HttpPost]//[AuthenticatePlz]public HttpResponseMessage Message([FromBody] string contents){    _service.AddMessage(contents);}And some domain service has the method that does the real biz://[AuthenticatePlz]public void AddMessage(string contents) {    // probably do some content checks or something and save the message}Don't get too hung up on whether Aspects are being used, or some Owin middleware, or Line 1 of the method is an Auth call, or some other horrible implementation.  The goal is: Should the interception point, where Authentication is required, live on the Endpoint or the service method?
Authenticate in the Services? Or in an Endpoint that exposes the Services?
c#;authentication;domain model;services