Since Auth0 has removed token delegation for new clients, I’m unable to use my firebase web app in a newly setup prod account. The documentation regarding this V8 migration is minimal and doesn’t provide enough info to build a solution in a “new way” (if one even exists). Countless posts on here regarding this and no real answers. Can anyone at Auth0 provide a clear, actual code example of how to use Auth0 with Firebase for new user’s? I’m using passwordless login.
I started off a total Auth0 evangelist, spent hundreds of hours this past year integrating Auth0 into multiple apps, ran into lots of deprecated issues, but there was always a solution if I kept trying. This though, just might be final nail in coffin for me, starting to see that I’m just hanging on because I have so much time invested in it, a sunk-time fallacy.
You can look at this from the perspective that the ability to use delegation and as such the built-in integration for Firebase was removed in the new OIDC compliant/API Authorization flows or from the perspective that OIDC compliant/API authorization was released as soon as it covered the most general cases.
If the OIDC compliant/API Authorization flows were only released when they also had built-in integration with Firebase we would not be in this situation of me having to say that in those flows there is not yet built-in support for Firebase and other similar integrations, however, we would also had deprived a lot of other customers of using something that was suitable for all their scenarios only because we wanted to release it with full parity even if that meant they had to wait for features that they might not even require.
In conclusion, there would always be an opportunity for us to irritate a particular subset of users; I honestly think that releasing early for the general scenarios was a good choice, but I also admit that we weren’t proactive enough in updating documentation to reflect those gaps and warn developers about them.
Going back to the original problem, as you might have read in other posts, new tenants created after the cutoff date can’t use the legacy flows; this may not gain any sympathy, but it’s better than allowing a dependency on something that is now considered legacy and will go through the associates stages of a legacy feature which ultimately end up in being removed altogether.
Existing tenants can still use it so that they would not suffer breaking changes and have time to migrate from it when a new approach is available. In addition, given not everything is black and white if you’re in a situation where you already took a dependency on the legacy flows because you developed your system in a trial tenant and now simply want to move it to production under a different tenant and that tenant (unlike the development one) was created after the cutoff date then I’m more than happy to try everything I can to get the same level of features available to both your tenants. If you’re in this very specific condition then please let me know.
@jmangelo thank you for the explanation. Frustratingly I am in the subset of users which rely on this sort of integration. Is there a supported workaround to allow services like Firebase to be integrated in a different way? What’s the recommend approach for new users now that the ‘legacy’ grants have been deprecated?
As an aside: ‘deprecated’ usually means not recommended, and changing in future… not stone cold unsupported.
@craig1 at this time, tenants that don’t have access to the legacy grants will have to handle the brokering of trust between the authenticated users and Firebase themselves (like the possibility mentioned by Adam).