All identity comes down to two things: Authentication which determines who you are and authorization which determines what you're allowed to do.
OAuth (1.0 / 2.0) is standard protocol made popular by social media providers that allows you to sign in with your existing account to another service. There are various authentication "flows" (ways to login and communicate with the app asking for permissions) with different security requirements for websites, mobile apps, backend services and other scenarios. The end result of a flow provides the requesting application a set of claims, which is a simple key/value list of attributes. There are standard claims like userid, email, and name but can include your birthday, customer id, or anything else.
OpenID is another standard protocol for authenticating to external apps from a single account but focused only on authentication. It tells a requesting application who you are but doesn't provide anything about what you're allowed to do or what information can be accessed.
OpenID Connect (also called OIDC) is modern protocol that merges OAuth and OpenID into a single system that lets an app know who you are but also optionally ask for other data (like permissions or profile details) if available. This is used by all major services now including Facebook, Twitter, Google, and Microsoft. You can easily add any OIDC provider to your app since they all follow the same standard. Other protocols include SAML, ADFS, WS-Fed and others used by big enterprises.
A neat feature of OIDC is that it can be chained. Your app can ask OIDC provider A for credentials, and this provider can then forward the user to another provider B to sign-in. Realistically these scenario is limited to 2 or 3 hops at most to avoid browser issues and excessive latency.
The technical concept behind all of this is called token-based auth. OIDC providers send back a "token" which is an encrypted piece of text that contains the requested data. There are ID tokens and Access tokens. An ID token is provided after the OIDC sign-in process (which is an encrypted payload of claims as described above). Tokens can expire and require another auth flow to refresh access.
JSON Web Token (commonly called JWT) is a badly named but standardized way that these tokens are formatted. It uses certificate-based signatures to prove the integrity of the data payload. It's unfortunately bloated by the JS ecosystem but has become the standard across the web and works well enough. This format is also commonly used to send credentials to the backend or API from a frontend JS app without using cookies.
I recommend just using cookies if you serve your frontend from a backend server that you also control since many frameworks provide strong support for cookies already.
There are many open-source systems like IdentityServer, Keycloak and Ory for implementing OAuth/OIDC in your own apps. Providers like Auth0.com, okta.com, AWS Cognito, Azure AD B2C, Google Cloud Identity / Firebase Auth let you offload the security to save time and effort.
For a more in-depth walkthrough, Okta has one of the best videos covering OAuth 2.0 and OpenID Connect: