Oauth2 is commonly used to protect APIs. It's very simple in that mode. Use your credentials (user password or whatever) and get a token with some expiry time and use it. When it is about to expire, get another one via a refresh API. Most well known REST APIs have used this for the last 12 or so years and it's not hard to implement even without a lot of library support. Most importantly, it follows the principle of the least amount of surprise. People who have used web APIs before, will have likely dealt with this before. I've been building APIs with some form of OAuth2 api protection for many years. Its a very standard thing at this point. I've also used NTLM and OAuth1 tokens for this in the past. Simple HMACs also used to be a thing with e.g. xml-rpc. And before that people just passed around session cookies; which especially over http had some obvious security issues.

These days, many APIs are stateless and there is no server side session. There's just authentication tokens. These tokens may be random numbers, some kind of signed token, or a JWT. Which it is does not really matter for the user. It's just an opaque string. In the case of JWTs the string might be a bit long and contain some data.

The notion that OAuth2 is not about authentication is kind of a half truth. You use your user/password or some other credentials to get a token via one of its flows. So, that is an authentication process of course. That token gives you access to an API. That's technically authorizing access. However, when you make requests to an API that is stateless, it's also a form of authentication. It does not know who you are until it inspects the token. The process of verifying that somebody is who they claim to be is usually called authentication. And a typical OAuth2 API will do that by verifying the signature of the token.

The token might also include information as to what they are actually authorized to do (e.g. via a scope or some other sort of claim in a JWT). But that is optional. I typically use role based security and I don't rely on tokens to transmit any information about which roles a user has. That is simply looked up from a database when the request comes in and used to determine which of a very long list of privileges they have. We assign roles to users and we verify privileges to authorize their access. If an admin assigns new roles to a user, their tokens are still valid but they are now authorized to do different things with it. So arguably, it's an authentication token and not an authorization token if you use it like that. The actual authorization is based on what roles you have. The token does not include any information about that. It just confirms that the user is who they claim to be. It could include that of course and with some APIs that is a thing. But with ours it just isn't. It's just an identity proof and we use it exactly like we would use a user password combination: we verify it is correct and valid.

Most modern apps don't have a notion of server side sessions. That's a thing from late last century and the beginning of this century. You can still do that of course but it's just less common unless you use stuff like ruby on rails or some older php frameworks.

But most full page applications or mobile applications talk to APIs using tokens. If your app is like that, I'd argue that you'd pretty much should support oauth2 unless you have a really good reason not to. And that that is not such a big deal. Not all of it but just the handful of the flows related to getting a token via the login flow and (optionally) refreshing it. The simplest way to get a token is basic authentication over https. You can implement a few variations of that that e.g. use a basic authentication header; a post form; a json API, etc. The standard is not particularly concerned with naming and form of things unfortunately. That's always been the issue with OAuth; there's too much freedom with respect to naming things, what to actually send over the wire, etc. Using the token usually means passing an Authorization header with as the value "Bearer xxxx" where xxxx is the token. But I've also seen APIs where they simply shove that in a post parameter, the json or even the url. As a standard OAuth2 is both very complex and unders pecified. But the good news is that the easy parts of it are all you need. It's all the less common flows that you probably should not worry about because you don't need them.

OpenID Connect has the similar issues. Very common if you want to add a e.g. Github or Google authentication flow to your website. It's a bit better standardized but still with a lot of annoying vendor specific variation in each implementation. And it may or may not include authorization information. Technically the tokens you end up with are either used as OAuth2 tokens or used to get one. It's ultimately just a convoluted way to get an OAuth2 token.