How to implement the same authentication mechanism for both the asp.net mvc and web API

Question

Goal is to create an api that can be shared by native mobile devices (ios, android, win phone) as well as web applications with various presentation layers (asp.net core MVC, angular).

Planning on using asp.net core web api for implementing a REST api that will be used by the mobile clients as well as javascript clients. My question is since other presentation layers like asp.net MVC will be used where ideally should security logic be placed? If we add the checks in the REST api then the asp.net MVC application controllers would have to call the REST web api using HttpClient instead of just referencing the business layer (shared class library).

The authentication of each application will be handled by json web tokens as they are mobile friendly and can scale easily. So my question is really about the authorization security and where it lives.

Option 1:

web api (security lives here) > business/service layer > data access layer > data layer

Option 2: web api > business/service layer (security lives here) > data access layer > data layer

In option 1 this is fine for mobile and client front-ends as they have to call the REST api, but the asp.net core MVC would have to use HttpClient to call the REST api instead of calling the shared class library that makes up the buinsess/service layer.

In option 2 all the REST api is responsible for is to call into the business/service layer where the security is handled there.

Answer 1

Sounds like you're aiming to build a Public API. This should be standalone and handle security by itself - the MVC website is just another client (that might happen to live in the same solution), but ideally you shouldn't have too many references between them (basically just the API contract). This way you'd also be able to catch broken backwards compatibility issues earlier, instead of the MVC site always working in a strongly typed manner (even through refactorings), while the other (especially mobile clients) wouldn't - you'll have to resort to versioning the API.

Performance really shouldn't be an issue if you take certain measures on the server side (eg caching), there's tons of APIs that work in this fashion.