At the most basic yes, but the protocol doesn't describe what the login part is and how that works. Often it implements session using cookies, which given the state you were in previously. Maybe you wanted to embed the login page on your own site (iframe or webview), now the cookies are flagged as third party cookies and blocked in a variety of context.

Especially in an app context it becomes a minefield of half baked webview implementations, browser specific quirks, and limitations on how to call back to the host app which initiated the flow.

Other questions are how do we handle return urls, i.e. return to where we started the login flow from? there isn't a good answer in oidc, unless you use some of the more extreme flows. It becomes tricky to implement without opening yourself to open redirect attacks, which kind of voids the benefits of oidc (that you don't have to handle the complexity of the authentication).

Also there are endless variations of the oidc flow, the most common being code flow, which is pretty much what you describe. But it gets increasingly complex as you have to handle native app login (PKCE pronounced pixie). Using these flows you end up becoming as much an expert in the technology as you would've been just implementing authentication and identity yourself.