TL;DL not really, but you may as well use some of it.

Almost any single page application needs some way of communicating with the server to get the data they want to work with. And many of them want to have personal data, with means knowing who the user is. The traditional way of doing this was with session state, but this doesn't scale well. More recently there is more emphasis on access tokens - essentially session state stored on the client instead. This scales a lot better, but you need some way to get a token to use.

This is often where things like OAuth2 or OpenID Connect come in. These offer frameworks in which a client can obtain an access token to use to talk to the server. And they are very hard to implement correctly.

My personnel recommendation is to ignore the bulk of OAuth2 for now. Implement access token auth in your server, and implement a simplified version of OAuth2 implicit flow, and leave it there.

What do I mean by the simplified implicit flow? You simply have a single page you open for the user to log in with, that redirects to a hard coded URL with the access token details. This hard coded page can then access a JavaScript function in its windows parent and pass the access token to that. Job done. No need to worry about Client Auth, Scopes, Redirect URIs, Refresh Tokens, support for multiple flows, or any of the other stuff needed.

Doing this, you're also in a position that, should you need to, you can actually implement OAuth2 in the future and it just drops in. Or you can use third party auth - e.g. Google or Twitter - and it just works. Very simple to implement and very little to change should it need to be reimplemented in the future.

Remember - YAGNI and MVP are king. Don't do things until you need to, because you might never need to.