Sample app for MVC client credentials

Help
1

Is there a sample app available for implementing the client credentials grant to secure an MVC app? Most examples here and elsewhere use APIs.
Our specific use case is to provide secure app to app communication but in our case the resource is an MVC app (an older one - .NET 3.5 MVC2 - could upgrade if necessary).

Update 1: (as follow-up to @jmangelo answer)

Regarding the key point you made:

…the MVC application must have a HTTP-based API that provides responses that can be consumed by another application and that API can be called with OAuth2 bearer access token

I don’t think so. Like most projects I inherited, it’s got all of the markings of something thrown together very hastily that follows no coherent pattern - but there is definitely no API present.

Here’s what I thought might work. We’d add some middleware to the MVC app that accepts and validates a bearer token which would then make the controller methods (guarded with [Authorize] attributes) now accessible to the client making the request.
I’m getting hung up on the part about the:

HTTP-based API that provides responses that can be consumed by another application

So basically I’m having trouble understanding how this fits together and will be looking for additional assistance. If you have any ideas with where I might start, please share.

Update 2:

Indeed, the use case is to obtain already rendered HTML. The Resource that needs to be secured serves web pages as opposed to raw data.
The client application would be another website or web application - so I suppose that the client wouldn’t necessarily be consuming the Resource - just gaining access to the web pages in the Resource.
From their web application they would submit their client credentials to us, we would verify those and then send them an access token and they would then use that token in their request to our MVC Controller - which would show them a web page.

So this is something that I’m interested in:

HTTP-based API consumed programmatically maps to your MVC controller methods

One of the samples you provide (I think it uses .NET core) shows the client credentials flow for an API. Are you suggesting that I might be able to modify that sample solution so that the API returns web pages instead of data?

2

The client credentials grant is somewhat linear to implement from the perspective of the client application as it’s just a single HTTPS call to the token endpoint, /oauth/token, followed by some JSON parsing to process the response. The grant as specified by OAuth2 allows a client application to obtain an access token that would allow it to call a resource server on behalf of itself, that is the access token is not associated with an end-user, but with the client application.

In addition, extension specifications to OAuth2 go on detailing how the access tokens are used to call the resource server; the type of access token in most widespread use is the bearer access token (aka the only thing needed to make an authorized call is the token) and resource servers will generally allow you to pass the access token using either:

  • the HTTP Authorization header with a Bearer scheme;
  • a form-encoded body parameter named access_token;
  • an URI query parameter named access_token.

Some resource servers only allow a subset of the methods described, usually the top one. In your case as long as your MVC application is configured to accept a bearer access token as means to access the underlying API then you’re okay. The key point is that the MVC application must have a HTTP-based API that provides responses that can be consumed by another application and that API can be called with OAuth2 bearer access token. The MVC application may also allow other authorization methods, for example, it may also support calling the API if you have a session cookie, which would likely be the scenario when an end-user accesses the MVC application directly. However, for an application to application scenario following OAuth2 rules it should support bearer access tokens.

In conclusion, the complexity of your scenario is all dependent on how the MVC application that is going to act as a resource server is already implemented. If it was implemented in a way that was already defining a clear programmatic API then at most you may need to introduce bearer tokens as another authorization mechanism and you would be set. Finally, the fact that the resource server in your case is an MVC application is an implementation detail, however, most resource servers are implemented with more specific technology (in .NET it would be the Web API) this means that is more difficult to find applicable sample code.

(Update 1)

Your approach of adding middleware so that access to controller methods can also be gained by providing an access token issued through client credentials makes sense. If you map that to what I previously said (although in a generic way) you would have:

  • HTTP-based API consumed programmatically maps to your MVC controller methods
  • …can be called with bearer access tokens maps to your implementation of the middleware that process the access token and outputs something that meets the Authorize requirement

I initially focused on the point that the API had to be suitable for consumption by another application because if the existing MVC controller methods only output rendered HTML you may have an hard time consuming in the client application side unless your use case is exactly to obtain already rendered HTML, but usually programmatic consumption of an API expects another output format like JSON or XML.

(Update 2)

You can use available API quickstarts, particular the .NET ones, as guidance, however, I’m not sure how much they would apply if you’re not using the exact same technology stack. They could probably be useful to understand what’s needed to be done to accept OAuth2 bearer access tokens, not so much for direct code reuse.

If on the other hand you’re inclined to switch tech stack/implement an API using one of the supported quickstarts technology stacks and then just return the same output as your current MVC controllers this by itself should be supported but it’s mostly out of scope when looking at the perspective of Auth0. Saying other way, you’re free to implement a .NET Core API and then return HTML instead of JSON. However, the decision on which approach to follow will need to be done by you as you are the one with most information about all the details.

A final comment, you mention that an entity would submit the client credentials to you and then you would validate and return them an access token. Ideally, if you provide a third-party with client credentials, after you created the third-party client in your account, they can exchange it for the access token by directly invoking the token endpoint of your Auth0 account. Check the reference docs for more information on client credentials and how to perform the exchange.

3

I updated my answer with some additional clarifications that try to address your follow-up.

4

Just provided a second update to my answer.