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!
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!
Hello thank you for this article,
The BFF pattern is better than the PKCE flow because using cookies with httpOnly is more secure than storing the token in local storage.
Is it possible to use this pattern for a React and Node application. The React and Node app are not deployed in the same domain.
I don’t understand how the user is redirected to the React app after logging in.
Hey @MehdiJarraya,
Welcome to the Auth0 Community! 
A fundamental requirement for implementing the BFF pattern for authentication and authorization is that the client is served by the backend (see here).
In your case, the React app must be served by your Node application. So they need to run on the same domain. In other words, from the authorization server’s perspective, the combination of your React+Node application is considered one application, and specifically, as a server-rendered application (i.e., confidential client).
In this scenario, I think it should be now clear how the user can be redirected to the React app after logging in. The React app is not an autonomous SPA since it’s served from the same domain as the backend.
1 Like
I work together with @MehdiJarraya. I have a few additional questions for you to further clarify the situation.
Currently the front-end(react) and back-end(node) are separate applications. Running on Front-end: app.xxxx. com and back-end: web-services.xxx. com.
So if we wanted to use the bff pattern they should both run on the same url?(which should be possible if we want this kind of change). And have a setup like xxxx.com and xxxx.com/api.
What is the difference between bff pattern and token handler patterns?
Thank you in advance!
Hey @maciej.glowacki,
Running the frontend and the backend under the same domain is a prerequisite for the BFF pattern. However, it’s not just a matter of publishing two separate applications under the same domain. Your backend needs to handle authentication and token management on behalf of the frontend, and your frontend needs to know how to interact with your backend to authenticate users. Your backend must act as a regular web app, which can also expose API endpoints.
I’m not familiar with the token handler pattern, but as far as I understand, it’s a variation of the BFF pattern to make the backend be an API instead of a regular web application. However, even in this case, you need to adapt both the frontend and the backend to enable authentication and token management.
Not sure how the token handler pattern can be better than the BFF pattern. As I said before, I’m not familiar with it, and as far as I can see, it’s not as popular as the BFF pattern.