These three concepts are largely orthogonal, but pair well.
Cookies are a state management system for HTTP, which is normally stateless. Rather than representing state via data embedded in the URL or requiring intelligence in the HTTP stack to represent that state in application-specific headers, Cookies allow the server to set state on a response which will be returned on subsequent requests. The browser doesn't need any special rules behind the generic cookie retention rules.
Cookies can be used for any sort of state, but in this context you probably care about authentication/authorization state.
Nearly every website which uses a web-based authentication flow (including OAuth and OpenID Connect) winds up using cookies to track authentication state.
OAuth is a HTTP-based framework for providing delegated authorization. Rather than sharing user credentials with every piece of code which may want to access resources associated with a user, the Authorization Service handles authentication as well as user consent to let a client act on their behalf. While there are several flows to account for different application requirements, this eventually results in an access token, a usually time-limited value which represents access to just the capabilities the user consented.
Facebook, Microsoft, and Google all use variants of OAuth to share user authentication as well as provide access to user information and API access to user accounts. There are challenges to OAuth interoperability, with many deployments adding additional capabilities outside the specification (such as representing user authentication). Facebook has their own extensions, while Microsoft and Google support the more standardized OpenID Connect as a interoperable profile.
Since the access token is state, there is nothing forbidding it from being set as a cookie. However, anyone who can get this token can perform actions as the user (bad) as your application (from a purely selfish perspective, worse). Many server-side web applications which store access tokens will either store them in a database and reference the row in a cookie, or store them in an encrypted cookie to prevent them from being extracted and used externally. One way to store such data in an encrypted cookie is via a JWT.
A JSON Web Token is a data format defined by the OAuth working group. Access tokens are really messages for the "Protected Resources" in OAuth parlance - typically API endpoints. However, the core specification did not define any format for these values, leaving them deployment-specific. JWT was an attempt to provide a good recommendation for the format, and was also designed to be leveraged by OpenID Connect (which both extend core OAuth with new functionality and provide an interoperable profile of usage).
It is typical that since security is hard, formats that take security into account (such as JWT) wind up getting both overused and oversold. People want to be able to say things like "our authentication is secure because we use JWTs", but instead statements like that are usually a red flag that the system was implemented by people who did not understand the overall security requirements.
Cookies are a state management system for HTTP, which is normally stateless. Rather than representing state via data embedded in the URL or requiring intelligence in the HTTP stack to represent that state in application-specific headers, Cookies allow the server to set state on a response which will be returned on subsequent requests. The browser doesn't need any special rules behind the generic cookie retention rules.
Cookies can be used for any sort of state, but in this context you probably care about authentication/authorization state. Nearly every website which uses a web-based authentication flow (including OAuth and OpenID Connect) winds up using cookies to track authentication state.
OAuth is a HTTP-based framework for providing delegated authorization. Rather than sharing user credentials with every piece of code which may want to access resources associated with a user, the Authorization Service handles authentication as well as user consent to let a client act on their behalf. While there are several flows to account for different application requirements, this eventually results in an access token, a usually time-limited value which represents access to just the capabilities the user consented.
Facebook, Microsoft, and Google all use variants of OAuth to share user authentication as well as provide access to user information and API access to user accounts. There are challenges to OAuth interoperability, with many deployments adding additional capabilities outside the specification (such as representing user authentication). Facebook has their own extensions, while Microsoft and Google support the more standardized OpenID Connect as a interoperable profile.
Since the access token is state, there is nothing forbidding it from being set as a cookie. However, anyone who can get this token can perform actions as the user (bad) as your application (from a purely selfish perspective, worse). Many server-side web applications which store access tokens will either store them in a database and reference the row in a cookie, or store them in an encrypted cookie to prevent them from being extracted and used externally. One way to store such data in an encrypted cookie is via a JWT.
A JSON Web Token is a data format defined by the OAuth working group. Access tokens are really messages for the "Protected Resources" in OAuth parlance - typically API endpoints. However, the core specification did not define any format for these values, leaving them deployment-specific. JWT was an attempt to provide a good recommendation for the format, and was also designed to be leveraged by OpenID Connect (which both extend core OAuth with new functionality and provide an interoperable profile of usage).
It is typical that since security is hard, formats that take security into account (such as JWT) wind up getting both overused and oversold. People want to be able to say things like "our authentication is secure because we use JWTs", but instead statements like that are usually a red flag that the system was implemented by people who did not understand the overall security requirements.