tl;dr: In your particular case, theres no reason not to use token based authentication. Your OAuth provider will probably provide you with JWTs anyway. You need to make sure your tokens are appropriately protected (use TLS, pick an appropriate lifetime).
Its a bit of a myth that theres anything inherently wrong with sessions for maintaining state. Its true that HTTP is stateless, and REST (since it closely mirrors the underlying protocol) works best when its also stateless.
An entirely stateless application, however, is extremely limited. For anything non trivial, you need to store some state, somewhere. You can either rely on the client to store this state (in the form of cookies, or some other local storage), or ask the server to store it in some form. The two main considerations you need to make are:
- How much state you need to store
- How sensitive is the data
If you have a lot of application state, storing it in the client passing it along with every request will increase latency for your application, and if your data is very sensitive, you need to ensure that you have provided suitable protection (encryption) or you dont pass the state to the client at all.
In the case of OAuth2, the tokens passed back to the client are effectively the state (representing authentication). These can either be in the form of JWTs (where the information is contained in the token itself) or some form of reference token, that the server can use to look up the pertinent information.