![alt text][1]Is it true, as indicated in the topic summary for Udemy course Server Side Rendering with React and Redux, that JWT and server-side-rendered React apps don’t mix? By extension, is it true that Auth0 and server-side-rendered React apps don’t mix?
Personally I don’t think this will boil down to a black and white sort of answer; there are a lot of (unavailable) details that would influence the yes or no vote. In addition, there’s some issues with how loosely we (developers) use the JWT terminology. In practice JWT is just a token format, however, it’s sometimes used to mean a lot of different things.
For example, if you take the use of JWT in that course to mean the use of bearer access tokens (which happen to use JWT as the representation format) then yes, I would mostly agree that for a server-side rendered application the traditional cookies approach is likely the recommended one. The use of bearer access token is more aligned with HTTP API’s.
However, to bootstrap a cookie-based authentication session you still need to obtain some proof about the user identity and it would be completely normal to follow the OpenID Connect protocol in order to obtain an ID token (which by spec is always represented as a JWT) that contains information about the authentication operation that took place (including user information). In this scenario the server-side rendered web application would still be using a JWT (the ID token) as a way to get proof about who the user is and then bootstrap the authenticated cookie session.
In conclusion, the answer to your first question about if JWT and server-side rendered applications mix is (drum roll) it depends (as almost every answer to software development questions). In relation to the second question, I don’t see how Auth0 (or any other service that uses OpenID Connect protocol) would not be a good fit for a server-side rendered application.