Subscribing always results in a 401 after updating to Mercure 1.0

[acelaya]

I have been working on updating my system to Mercure 1.0, by following the upgrade guide, and the information from the release notes

The main changes I had to make were on updating the JWT structure, specifically by applying these changes from the breaking changes notes:

Tokens. The bespoke mercure JWT claim is replaced by an OAuth 2.0 access token: typ: at+jwt, an iss matching a trusted issuer, an aud holding the hub's resource identifier, a required exp, and an authorization_details array of { "type": "https://mercure.rocks/authorization-detail", "actions": [...], "topics": [...] } entries. topics holds { "match", "match_type"? } objects — bare strings are rejected, match_type is case-sensitive and defaults to exact, and { "match": "*" } still matches everything. A subscribe entry carries its own payload; the top-level mercure.payload is gone. The claim must be unambiguous JSON: a duplicate member or invalid UTF-8 rejects the token rather than letting the hub pick a reading the authorization server may not have validated. One invalid detail rejects the whole token.

With this I managed to make publishing work, but I keep getting a 401 error when trying to subscribe via javascript's EventSource. I assume I'm missing something in the token, but it could be something else.

This is how my JWT looks like once decoded, for a token which is intended to allow subscribing to any topic:

// Headers
{
  "typ": "at+jwt",
  "alg": "HS256"
}

// Payload
{
  "iss": "MyIssuer",
  "iat": 1791552014,
  "exp": 1791638414,
  "mercure": {
    "subscribe": [
      {
        "match": "*"
      }
    ]
  },
  "aud": "http://localhost:3080/.well-known/mercure",
  "authorization_details": [
    {
      "type": "https://mercure.rocks/authorization-detail",
      "actions": [
        "subscribe"
      ],
      "topics": [
        {
          "match": "*"
        }
      ]
    }
  ]
}

On top of this, I have set MERCURE_TRUSTED_ISSUERS=MyIssuer.

One thing I don't know is what are the allowed values for the actions prop inside authorization_details. For publishing it worked once I set publish there, so I assumed for subscriptions it should be subscribe, but I haven't found any documentation stating this.

EDIT: Subscribers try to subscribe via:

const hubUrl = new URL('http://localhost:3080/.well-known/mercure');

hubUrl.searchParams.append('match', 'https://example.com/some-topic');
hubUrl.searchParams.append('authorization', '...']); // The JWT is set here

const es = new EventSource(hubUrl);

[CaptainAni187]

Your token looks fine. actions takes publish and/or subscribe, so ["subscribe"] with { "match": "*" } is right (the leftover mercure claim is just ignored). The problem is how the token reaches the hub.

1.0 removed the authorization query parameter. From the "Migrate token presentation" section of the upgrade guide: "The authorization query parameter is gone and has no replacement", because RFC 9700 forbids access tokens in URLs. So the hub never sees your token and answers 401.

For EventSource in the browser, which can't set headers, the replacement is the cookie. Its default name changed from mercureAuthorization to __Secure-mercure_access_token. Since you're on http://localhost, keep in mind that browsers only accept __Secure- cookies over HTTPS, so for local development set a name without the prefix with the hub's cookie_name option and use that. The cookie has to be sent to the hub, so it needs to be set for the hub's domain, and with withCredentials: true if the hub is on another origin:

const es = new EventSource(hubUrl, { withCredentials: true });

Outside the browser, or with fetch() and a readable stream, send Authorization: Bearer <token> instead. That header is unchanged and takes precedence over the cookie.

[acelaya]

1.0 removed the authorization query parameter. From the "Migrate token presentation" section of the upgrade guide: "The authorization query parameter is gone and has no replacement"

Oh, I completely missed that sentence. But I had a strong suspicion it had to be that.

I'll see if I can set that cookie somehow, since the host generating the token is different than the one where the hub is.

Thanks for the tip!

[dunglas]

@CaptainAni187's answer is right. Sorry for the confusion: until yesterday mercure.rocks was serving an outdated draft of the 1.0 docs, including the upgrade guide you followed. The updated guide now documents the change. The leftover mercure claim in your token also came from that draft; you can drop it.

A few details for your local setup:

• With the official Docker image, set the cookie name with MERCURE_EXTRA_DIRECTIVES=cookie_name mercure_access_token.
• Set the cookie HttpOnly with Path=/.well-known/mercure.
• With withCredentials: true, add your app's origin to cors_origins on the hub. * doesn't work with credentials.
• A 401 whose WWW-Authenticate header has no error="invalid_token" means the hub received no token at all.
• For the Authorization header route in the browser, a fetch()-based SSE client such as @microsoft/fetch-event-source works.

[dunglas]

The server is serving the new version now, so it's probably a cached page in your browser. Try a hard reload (Ctrl+Shift+R / Cmd+Shift+R) or a private window. The current guide has a "Migrate token presentation" section, and the mercure claim only shows up as the 0.x "Before" example. If you still see matchURLPattern or lastEventID anywhere, let me know.

[acelaya]

Yep, I can see the right one now

[acelaya]

I managed to make it work by generating the cookie on the fly in JS. My BE, FE and Mercure Hub are all served from three different domains, so I couldn't generate the cookie server-side.

I used to use the Authorization header approach by using a custom EventSource library (similar to @microsoft/fetch-event-source), but I ended moving to the standard one because the library was pretty much unmaintained.

When I did that, for some reason I assumed I couldn't generate the cookie client-side, hence I decided to go with the less secure authorization query param.

Thanks @dunglas and @CaptainAni187 for your input.

[acelaya]

I managed to make it work by generating the cookie on the fly in JS

Actually, scratch that. I didn't realize that in my dev env all three services are served from localhost, just in different ports, so technically the domain is the same. But when moving to an env with fully different domains, JS rejects the creation of cookies for other domains (as it should).

I probably faced this back in the day, that's why I ended up using the authorization query param to avoid using an extra dependency. I don't understand what's the reasoning for the standard EventSource to not let you set headers 🤔

[dunglas]

There is some work in progress to add headers support to EventSource: whatwg/html#2177 (comment)

Don't hesitate to support and review the proposals.

In the meantime, for your use case, using a polyfill is the way forward.