Auth0 Home Blog Docs

Combining cookie and token authentication in dotnet core 2.0

dotnet-core

#1

Using ASP.NET Core 2.0. The code is running in a Windows 10 machine (it’s a proof of concept). We need to allow for our .NET Core application to

  1. Authorize access based on either cookie or JWT bearer token
  2. Return either HTML (UI) or JSON (API) responses based on Content Negotiation

There’s an example of doing this in .NET Core version 1 here: https://github.com/auth0-samples/aspnet-core-mvc-plus-webapi but the API for .NET Core 2 has changed significantly and we’ve not been able to adapt the approach. We raised an issue here: https://github.com/auth0-samples/aspnet-core-mvc-plus-webapi/issues/1.

Does anyone have an example of how to do this?


#2

Hi Andrew. I did the original sample but I’m afraid I missed the GH notifications of you looking for an update for .Net Core 2.
To be completely honest, I’m not sure anymore that it’s a good idea to combine a token-based API with cookie-based authorization for interactive usage.
I assume that you want to make the API publicly accessible and not only confined to the web site. If so, personally, I feel that a better approach would be to:

  • Create a separate API service. This one would use token-based authorization, and would be available to use by external clients (that you register in Auth0). See https://auth0.com/docs/quickstart/backend/aspnet-core-webapi/01-authorization
  • Create a web site (meant for interactive use) that uses cookie-based authorization. When making a token request to Auth0, include the audience for the API you created.
    • Since this would be a regular web app, you can securely store the access token in the server (don’t send it to the client)
    • If you need to access the API from the browser for your regular web app (for interactive AJAX stuff), call an endpoint on the regular web app (cookie-based authorization). In the endpoint (server side) use the previously retrieved access token to make a backend call to the API.

Does that make sense? WDYT?


#3

Thanks Nicolas. We’re using a relatively new architectural approach which is sometimes called Micro-applications (or from a few years ago LOSA-style).

This style recommends that you create a single application which is capable of interacting with both machine and human (browser) agents and that you rely on content negotiation to determine the correct responses.

As it’s relatively new, I can understand if Auth0 doesn’t support it. I’m happy to record your recommendation against this architecture for the purposes of our RFP process if that’s Auth0’s stance on the issue.


#4

I wouldn’t say Auth0 doesn’t support it, nor that we recommend against it. This is more of a general application architectural style choice, independent of authentication and authorization. That choice is entirely up to you.

We try to keep samples as simple as possible so that the basic authentication and authorization concepts are easy to understand and can be used as a starting point. ~But I’ll upload a sample for .Net Core 2 later today or tomorrow in that same repo in case it helps.~

EDIT: A possibly side-effect of this architecture that I wanted to mention is that you tie the needs of your web site to the design of the public API, which could prove problematic as the app evolves, especially if you don’t control the other clients of the public API.


#5

@andrew.gibson I updated the repo at https://github.com/auth0-samples/aspnet-core-mvc-plus-webapi to .Net Core 2. Hope it helps.


#6

Thanks Nicolas. Thanks for this. I’m trying to combine two of these applications:

Browser -> App 1 -> App 2

and I’m able to sign in to App 1 using the code supplied. However, when I call App 2 from the controller in App 1 (passing the access_token obtained by App 1 as Bearer token) the call is not validated. It’s possible that I don’t have everything configured correctly. How are the ApiIdentifier and ClientSecret related?