Should I implement authentication for event messages in a messaging queue?

In "Enterprise Integration Patterns" (been using the book as a reference while I'm implementing a queue messaging system), there's the concept of a command message, document message, event message, etc.

In my system I've decided to use the "pull model" for event messages. So, when a document in the database updates, it broadcasts an event message like this:

routing key: 'UserUpdated'
body: { _id: '5787f132f50f7b03002cf835' }

Then, any interested observers can simply request via an RPC (request/reply) channel the most recent version of the document (a "User" in this case) and do what they need to do with that state in order to make changes in their own service (for example, when a user is updated, another system might want to know about it and then cache that user record in Redis or something).

In my other message types (for example, a command message like UpdateUser), I also send an authorization token in the message headers. This makes sense, because the command UpdateUser is meant to invoke a change in another system.

However, does it make sense to also put an authorization token inside of event messages?

My thinking is that the event isn't necessarily requesting a change on any observer, and doesn't need to be "authorized" just to notify a system about something that happened (besides, both systems are already connected to the same queue server, which required some authorization to begin with); instead, the observer simply sees some _id in the message, and requests a document separately, and then can make changes to its own service if it wants to (in the request of the document, the observer does supply an authorization token). Any thoughts?

For anyone interested in implementation details:

• node.js (with amqplib)
• RabbitMQ

via Josh Beam