Authorization with an OAuth token provided by an external web API

Question

I am posting this in the hope of getting some feedback / tips and information about what I struggled with in the last few days. First, I’ll briefly talk about the project.

There are 2 applications in the solution:

• WebAPI Resource and Authorization Server - Uses OWIN (hosted in IIS) and the ASP.NET identifier to issue an authentication token when logged in correctly and then resolves requests to various controllers.

• MVC client application . There is no authorization yet (I won’t find out yet), but it will call the WebAPI resource server to get all the data. These calls will be made only from the actions of the controllers in the client application, without AJAX calls on the client side.

The client application does not have its own data source. All information is stored in a database that the WebAPI service has access to, so if they provide the correct credentials and the client application receives the carrier token, I need to provide a way for the application to see them as authorized.

• What is the best way to handle this?
• Can I configure OWIN on the client side to use OAuth server settings? Am I barking the wrong tree and do I just need to use HTTPClients?
• Can I deserialize the carrier token and save it in the session, and then write my own authorization providers to check them on the client side?

My initial fears are that I am abusing the carrier tokens and trying to push them into a solution that is not ideal. All examples of external authorization that I have found so far usually include calls to providers hosted on Google / Facebook / Twitter to check which of them are who they say, and then proceeds to create a user record in their system. My application cannot do this.

Regarding security, I planned to introduce filters that would confirm that the request came from the client application, providing an identifier and a secret, along with an IP check.

I understand that this may be a little open, but I would appreciate any advice. The scope of the project is that the web service is only to have access to the database. The MVC client application will be hosted on another server, and the service will only accept requests from the specified client application.

Answer 1

You do not need to access the data source in your MVC application to verify the carrier token. Basically, you can do it like this:

• The request for the MVC application is access_token from webapi and passes it to the user interface client (say, a browser).

• The browser saves the access_token in the cookie / localstorage and sends them to the MVC application for all subsequent requests.

• Create an ActionFilter in the MVC application to check if the request from the browser has the token specified in the header. If not, reject the request.

• The MVC application passes the access_token in the Authorization header of the website.

• Use HTTPS for all messages (between MVC ↔ Client and MVC app ↔ WebAPI)

You can further confuse or encrypt the access_token that you get from the WebAPI on the MVC application side for added security, but then you will have to send the decrypted version back to the WebAPI.

Answer 2

I understand that my answer is a bit late, but maybe this helps other people:

The toner carrier you receive from the API contains a list of encrypted requirements that only the API can decrypt. I assume that you need to have these claims in your MVC application so that you can limit the resources on the client.

So what I did was get the token first. After receiving it, you make another request to the api / me / Claim API to get a list of readable requirements on the client. Based on this list, you can allow access to resources in your MVC CLient application using the Authorize attribute based on your own claims. In addition, you can store claims in a cookie in a client session. Below is the code for the API controller to receive complaints.

 [RoutePrefix("api/me/claims")] public class ClaimsController : BaseApiController { [Authorize] [Route("")] public IHttpActionResult GetClaims() { var identity = User.Identity as ClaimsIdentity; var claims = from c in identity.Claims select new { subject = c.Subject.Name, type = c.Type, value = c.Value }; return Ok(claims); } } 

The idea is to restore the registered user ClaimsIdentity object on the client side and possibly add it to the session.

Not enough token. Perhaps you run the risk of getting an unauthorized API response on a resource that you have made visible to the user in the MVC client application. Needles say that it is recommended to use HTTPS for all requests.