The straight answer would be, yes, it's possible and fine to rely on OAuth 2.0, however, the most honest answer would be it kind of depends and there's more than one way to do it.
Scenario 1 - Web and API are independent
If your Web application is completely independent and does not act as client of the API, my personal inclination would be to use an OAuth 2.0/OpenID Connect flow to get the user authenticated, receive a token that proves their identity and then create a regular session based on cookies. When I say regular session I mean a session that is stored server-side and the cookie only contains a unique identifier for that session.
You can also go ahead and store the actual token in the cookie and go stateless, but I honestly don't see the benefit. In most of the cases a Web application will want to store sufficient information in a session to make the idea of saving it all in a cookie just plain bad. Yes, you can save the access token and then still have session state on the server side associated with that token, but then what would you gain from saving the actual token.
Scenario 2 - Web is also a client of the API
In this case things may play out differently. Judging from your question your Web application is based on ASP .NET MVC so I will assume that the API calls will take place on the server-side.
I would still go with creating a regular session identifier in a cookie upon authentication instead of saving the actual token, but more important than that you'll have to decide what to do when the token expires, you can have the application session last as much as the token allows and then force the user to repeat the whole authentication process to get a new token, but unless your access tokens have a really long lifetime (which is generally frowned upon, not common and also not recommended) this is really bad for user experience.
My inclination to use a session identifier instead of the token itself is just because with bearer tokens if its not a functional requirement to have the token available to the client then don't do it, as otherwise you're just increasing the impact in case of a breach.
Personally, on this scenario I would resort to OAuth refresh token support to be able to keep refreshing the Web application access token while the user session is active. This way you can easily implement a sliding session that will be active as long as the user is and at the same time use access tokens with shorter lifetimes which reduce the impact of an access token being leaked.
Here's some resources for further reading about cookies/sessions and token authentication that may help you get a few different perspectives to support the decision process:
