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
- an URI query parameter named
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.
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
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.
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.