Set the 'X-Consumer-ID' header on successful authentication

Here is a POC with a plug-in system for the negotiators.

Never do copy-paste :D. Yes they should be different, as the original order should be enforced.
First the header and then the query negotiator.

Well simple_oauth is having the meta-data available to get the consumer UUID from the token being passed in.
I do not want to send consumer UUID on every request, as the data is already present and used during authentication.
Here is the decorator that solved it for me, changing simple_oauth behavior...

The main part is I am setting the header dynamically just after the successful authentication, so existing negotiators will kick in.

namespace Drupal\my_module;

use Drupal\simple_oauth\Authentication\Provider\SimpleOauthAuthenticationProviderInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestStack;

/**
 * Class OauthProviderDecorator.
 *
 * @package Drupal\my_module
 */
class SimpleOauthProviderDecorator implements SimpleOauthAuthenticationProviderInterface {
  /**
   * Provider to decorate.
   *
   * @var \Drupal\simple_oauth\Authentication\Provider\SimpleOauthAuthenticationProviderInterface
   */
  private $decorated;

  /**
   * Symphony's request stack service (current request).
   *
   * @var \Symfony\Component\HttpFoundation\RequestStack
   */
  private $requestStack;

  /**
   * SimpleOauthProviderDecorator constructor.
   *
   * @param \Drupal\simple_oauth\Authentication\Provider\SimpleOauthAuthenticationProviderInterface $decorated
   *   Decorated provider instance.
   * @param \Symfony\Component\HttpFoundation\RequestStack $request_stack
   *   Symphony's request stack service (current request).
   */
  public function __construct(SimpleOauthAuthenticationProviderInterface $decorated, RequestStack $request_stack) {
    $this->decorated = $decorated;
    $this->requestStack = $request_stack;
  }

  /**
   * {@inheritdoc}
   *
   * @see \Drupal\consumers\Negotiator::negotiateFromRequest()
   */
  public function authenticate(Request $request) {
    /* @var $result \Drupal\simple_oauth\Authentication\TokenAuthUser */
    if (NULL === $result = $this->decorated->authenticate($request)) {
      return NULL;
    }

    // Hijack the success authentication flow to access the currently active
    // consumer's uuid. Pass it as a new dynamic header on the current request,
    // so we can fool Negotiator::negotiateFromRequest detection.
    /** @var \Drupal\consumers\Entity\Consumer $client */
    $client = $result->getToken()->get('client')->entity;
    $request = $this->requestStack->getCurrentRequest();
    $request->headers->set('X-Consumer-ID', $client->uuid());

    return $result;
  }

  /**
   * {@inheritdoc}
   */
  public function hasTokenValue(Request $request) {
    return $this->decorated->hasTokenValue($request);
  }

  /**
   * {@inheritdoc}
   */
  public function applies(Request $request) {
    return $this->decorated->applies($request);
  }

}

This is related: #2962050: Strange interface.

So your suggestion at the moment is to put the decorator directly in the authentication service.

Here is a patch to resolve that directly on the auth service.

Changes:
- Marked the interface as internal (same as the only class implementing it).
- New accessor method added on the interface and TokenAuthUser class.
- Set the header on successful authentication.

It should be impossible to get a null, as the customer is set only when there is a valid consumer found in this method.
The rest is just property access.

/**
   * Constructs a TokenAuthUser object.
   *
   * @param \Drupal\simple_oauth\Entity\Oauth2TokenInterface $token
   *   The underlying token.
   *
   * @throws \Exception
   *   When there is no user.
   */
  public function __construct(Oauth2TokenInterface $token) {
    if (!$this->subject = $token->get('auth_user_id')->entity) {
      /** @var \Drupal\consumers\Entity\Consumer $client */
      if ($client = $token->get('client')->entity) {
        $this->subject = $client->get('user_id')->entity;
      }
    }
    if (!$this->subject) {
      throw OAuthServerException::invalidClient();
    }
    $this->token = $token;
    $this->consumer = $client;
  }

If you are getting an error as stated in the comment i think we need more info to resolve it...

Yea, there was the underlying issue that there was not a client instance in all cases. Here is a patch that should resolve the issue.

On top of that it shows that we have missing test coverage in case where user is set on consumer level, resulting in somewhat different authentication process (unified to a big extent now).

Are you using the patch, as I am seeing differences...
If there is no $client, you should be getting OAuthServerException in that case.

1. Here is a tweak that adds support for NULL consumers. Note that negotiators (needed by https://www.drupal.org/project/consumer_image_styles) will not trigger at that point.
2. @e0ipso, is there a case, where the token will have NO consumer associated with it? As I see it consumer is crucial part of a token, so why are they getting NULL values at all is a more correct question for further investigation...

Ok you are getting a token and an exception...
- How are the consumers configured?
- Any other modules that interact with simple_oauth?
- Anything specific to allow us to reproduce the issue?