Understand the Backend For Frontend authentication pattern and how it can be implemented in ASP.NET with Auth0.
Read more…
Brought to you by one of our Guest Author 
@cibrax
What’s up Devs! How did you like this post? Please share any comments or feedback with us on this thread 🧑💻
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
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 ?
That is a good question indeed. I haven’t addressed that in that sample, but it can probably implemented in two ways.
- 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
- Just use OpenID for the initial authentication, and client credentials on the backend for all the APIs
Thanks
Pablo.
t
It’s an interesting article, I have a few questions
- 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?
- 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?
- 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!
- 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!