For obvious reasons you’re unlikely to find someone that will certify a solution over the Internet; that situation is even worse in my case, because I’m replying as part of the Auth0 support team so it would be totally impossible to completely validate a solution as that goes beyond my job description. I can, however, discuss general recommendations and an additional point of view.
For the native mobile apps you seem to be introducing a middle-man that does not do any additional logic, it just translates requests from the application to an authorization server (Auth0). So, for this situation, this is mostly the same as using the resource owner password credentials (ROPC) grant directly from the mobile app. This has some considerations given the mobile application will need to process user credentials directly, however, usage of ROPC in mobile applications is something acceptable if you have very constrained requirements in the UX. In conclusion, your solution with an additional proxy is mostly the same as long as communication to the proxy is as secure as the communication that would occur if the authorization server was used directly.
For the SPA scenario you’re doing something much more custom and if there are sessions involved reducing that client application to a SPA seems a bit to much. Personally, I would just treat that application as regular web application that maintains its own session. In conclusion, I would personally not choose to move the access tokens to the browser-side and would just deal with a traditional cookie-based session and a back-end that handles such type of session (that back-end could make further calls to other API’s using access tokens, but that would be an implementation detail).