Whatever the flow, the MAC token would be generated the same: a symmetric secret key and an id is sent to the client once. This secret is never sent over the wire again.
The client doesn't validate the token*, the client uses it as it would use a bearer token, except that the secret is not sent over the wire and thus can't be leaked:
+--------------+ +--------------+
| |>------Request with authenticator------>| |
| | | Resource |
| Client | | server |
| |<--------Requested resource------------<| |
| | +--------------+
+--------------+ ^
^ |
| |
| |
| |
| MAC algorithm
MAC algorithm over key+params
over key+params
The client constructs the authenticator calculating a MAC using the secret key and some parameters (that includes the token ID, a nonce, a timestamp and some other data), and attaches that to the request.
The resource server (or a third server the RS uses to validate tokens) knows this secret key, so it performs the same calculations as the client did using the same params. If everything matches it proceeds with the request.
The server is also tasked with preventing replay attacks by checking the timestamp and preventing nonce-reuse.
This protects agains many scenarios in which the token could be leaked: TLS misconfiguration/bug, attacker controlled endpoints finding their way into the client's database, etc.
Regarding your 3rd question, yes and no. The OAuth2 MAC spec draft defines a few claims for JWT to encode the information required for the emission and use of MAC tokens using JWT, but OpenID Connect is still using bearer tokens.
The main concern with bearer tokens is that the client's developer has to be very security-aware, and that its security depends exclusively on TLS.
A lot of people misunderstand this last statement and conclude that OAuth2 is inherently insecure and useless and doomed. Even worse, they blindly repeat this kind of conclussions in talks and posts and comments and simply confuse people.
OAuth2 is very good for some use cases and sucks for others. It requires a good understanding of some security principles. It requires some compromises as well. But it's out there, it's working and it solves a very hard problem.
The use of MACs was never standarized, but the draft is pretty good and easily implementable. Today there are several alternatives as well.
(*): I mean the client doesn't perform MAC validation. Of course, audience and other fields should still be validated.