Even if the token is known to the consumer, you have to know on which OAuth session the returned user is operating on. In this step the token acts as a session identifier. Otherwise how would you know who the returned user is (unless you provide a session identifier in the callback yourself).

I advise you to adhere to the specification. Since you don't control the Consumer if you are acting as a Service Provider, you don't know anything about the callback requirements. If it is dynamic (e.g. including a session identifier like in 1.), you will have problems with a stored callback.

Again. Stick to the spec. Although it is not written in stone, a lot of smart people have been working on it and thinking long and hard about the implications of changes to the spec. Since one might not control both domains (Service Provider and Consumer), you have to agree on an authentication method. How would the domains know how to interpret the ciphers if they don't know about the method? What if the current methods are deemed unsecure? How do you find out if one party changed the method?

This function is supposed to be cryptographically secure. You can use it.