JWE and the key management modes

Wrapping my head around JWE and the key management modes. The point of JWE is to prevent third parties to see/change the token. Only the token issuer and resource server should be able to use it. (Is this correct?)

To encrypt the token's payload, we need to generate CEK (Content Encryption Key). This key is provided to the symmetric algorithm specified inside "enc" JOSE field. According to https://www.rfc-editor.org/rfc/rfc7516, we have 5 ways to get a CEK.

1. Key Encryption. CEK is randomly generated, payload encrypted using CEK, CEK encrypted using an asymmetric algorithm-public key - according to "auth" JOSE field, and embedded into the token. The resource server can discover-deduce the corresponding private key and use the asymmetric algorithm to decipher CEK. The resource server can discover the corresponding public key in many ways. One of them is jkw in JOSE header. jkw represents the the corresponding public key.
2. Key Wrapping. CEK is randomly generated, payload encrypted using CEK, CEK encrypted using a symmetric algorithm, and embedded into the token.
   How can the resource server decipher CEK in this case?
3. Direct key agreement. CEK is decided based upon a key agreement algorithm.
   Do in this case the issuer and the resource sever work together to get CEK first? Do they maintain a session for a while until the CEK is generated? Is this out of specification?
4. Key agreement with key wrapping. CEK is randomly generated.
   Why do we mention key agreement then?
5. Direct encryption. CEK exchanged out-of-band.

Thanks for any feedback.

The point of JWE is to prevent third parties to see/change the token. Only the token issuer and resource server should be able to use it. (Is this correct?)

Yes, the point of JWE is to provide confidentiality (only intended recipient(s) can see the contents), integrity (prevent the token from being tampered with). Some key management modes also provide authentication (ensure token was generated by issuer it claims to be).

Key Wrapping. How can the resource server decipher CEK in this case?

The issuer and the recipient must both have a pre-shared symmetric key used to decrypt the CEK. How do they share this key is out of scope of the specification.

Direct key agreement. Do in this case the issuer and the resource sever work together to get CEK first? Do they maintain a session for a while until the CEK is generated? Is this out of specification?

Key agreement is used for public/private key pairs that can't be used directly to encrypt data. This is the case of ECC keys which can only be used directly to perform digital signatures. The issuer and recipient use an algorithm that uses public/private ECC keys to derive the CEK.

Key agreement with key wrapping. Why do we mention key agreement then?

Because the randomly-generated CEK is encrypted using a key that was derived using a key agreement algorithm. This is conceptually the same as plain key wrapping but with ECC keys.

For more information about key management modes and when to use each, see this answer.