Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core

Blog Discussions
, , ,
#1

Understand the Backend For Frontend authentication pattern and how it can be implemented in ASP.NET with Auth0.
Read more…

:writing_hand:t2: Brought to you by one of our Guest Author :rocket: @cibrax

Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core
Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core1176×1056 77.4 KB

September Community News 2021
#2

What’s up Devs! How did you like this post? Please share any comments or feedback with us on this thread 🧑‍💻

#3

Very good article!

But I still have a question about the BFF pattern. What if the BFF serve for more than only one (1) API. Let’s say that instead of only have “WeatherAPI” there is also “LocationAPI”. How do you manage the access_token and audience in the BFF?

Thanks!

1 Like
#4

great article, but i’d like to know how can we use this for an app with multiple instances, im asking for the session mechanism. is redis a good fit for this ? how can this be achieved ?

#5

That is a good question indeed. I haven’t addressed that in that sample, but it can probably implemented in two ways.

  1. Add a new endpoint like login (which does a redirect to Auth0 for getting an access token for your other API). The only thing is that you might need a different secure store for the access token as I don’t think you will able to inject it in the same encrypted cookie that is used for the authentication session
  2. Just use OpenID for the initial authentication, and client credentials on the backend for all the APIs

Thanks
Pablo.
t

#6

It’s an interesting article, I have a few questions

  1. How do you avoid the problems of needing sticky sessions here? If you are caching on a server, then either the clients have to guarantee routing to a particular server, or you need some kind of distributed cache. That might be possible in a single region (say using a Redis cache) but what about multi-region deployments?
  2. If the BFF has to proxy all requests to secured backends, isn’t that likely to provide an intolerable maintenance overhead? If there are 30 secured APIs across half a dozen secured services, and any change in an API also requires a change in the BFF? Not to mention the mapping etc?
  3. Again, if the BFF has to proxy all requests to secured backends, doesn’t that mean it would need to scale to support the level of requests to all those backends? That seems it might be somewhat expensive!
  4. if the tokens are persisted in the encrypted session cookie, is there anything that forces the BFF to extract the access token and add that as a header on the forwarded request? Or could the destination API just accept the encrypted cookie forwarded on to it, unpack the cookie itself and utilise the access token within?

Thanks for listening, I hope these questions make sense!

#7

Hey there @cibrax!

Would you be able to follow up on that?

#8

Hi @cibrax , great article!

Just one question, how come this solution doesn’t fit to serverlessbackend:

This pattern does not work for a pure SPA that relies on calling external APIs directly from javascript or a serverless backend (e.g., AWS Lamba or Azure Functions).

Let’s say I have a SPA that it’s backend are cloudfront → lambda → EKS, why the BFF solution will not fit?

Thanks!