Notifications for Google Chrome are complaining about auth header format

[mblitherland]

Hi,

I appreciate the work you've done to make this library available and keep it up to date. I was working on implementing it in a project and it was going great, but when I started testing it with Google Chrome (Version 118, flatpak in Fedora Linux 39 beta here, but I've tried other Chromes as well, including 118 in Windows 10), it's failed with an error. The exact same VAPID key setup works for Firefox just fine. The error Google reports is a 403 with the body of:

authorization header had invalid format. authorization header should have the following format: t=jwtToken; k=base64(publicApplicationServerKey)

I haven't dug into the library code yet, but is this something you're aware of?

Thanks, Michael

[tpeczek]

Hi @michaellitherland,

My first guess would be that the authentication schema being used is WebPush, while Chrome requires Vapid.

Depending on how you are using the library, there are couple places where you configure that:

• The default is set through PushServiceClient.DefaultAuthenticationScheme.
• It can be set for specific delivery request as there are RequestPushMessageDeliveryAsync overloads which take it as parameter.
• The integration for ASP.NET Core enables configuring the default while registering the services through PushServiceClientOptions.DefaultAuthenticationScheme.

My guess is that WebPush is being used somewhere explicitly, as in general Vapid is the default and should be currently supported everywhere (WebPush is the older scheme and is becoming obsolete).

If my guess is incorrect, than I will need some more detail - ideally a simple snippet to repro.

[mblitherland]

Hi @tpeczek,

I logged the scheme in use and got *** auth scheme: Vapid (using Console.WriteLine($"*** auth scheme: {_pushClient.DefaultAuthenticationScheme}");,) so it appears to be using the right thing. I've already got the code pretty well isolated so I'll try for a simple test class. The only other thing I can think of is if there's something wrong with the way I generated the VAPID keys, but then why would FF, Opera, and Edge be OK?

Thanks for giving this some thought. I'll try to follow up with a simple sample shortly. Michael

[mblitherland]

I'm still debugging, but I did print out the request using the JSON serializer and it looks like this:

{
    "Version": "1.1",
    "VersionPolicy": 0,
    "Content": {
        "Headers": [
            {
                "Key": "Content-Type",
                "Value": [
                    "application/octet-stream"
                ]
            },
            {
                "Key": "Content-Encoding",
                "Value": [
                    "aes128gcm"
                ]
            }
        ]
    },
    "Method": {
        "Method": "POST"
    },
    "RequestUri": "https://fcm.googleapis.com/fcm/send/<subscription url details removed>",
    "Headers": [
        {
            "Key": "TTL",
            "Value": [
                "2419200"
            ]
        },
        {
            "Key": "Authorization",
            "Value": [
                "vapid t=<jwt removed>, k=<pub key removed>"
            ]
        }
    ],
    "Properties": {},
    "Options": {}
}

[mblitherland]

It was the key! I don't know why, but Chrome didn't like it even though FF and others were fine with it. I generated a new key and it's working. Thanks for the help @tpeczek, and sorry for the false alarm!

[tpeczek]

No problem, happy that you managed to get to the bottom of it.

[jlynch630]

I ran into this same issue as well so thought I should mention my fix for anyone else: My vapid keys were base64 encoded in a non url-safe manner (i.e using + and /). Once I switched the keys to the url-safe base64 encoding (-, _), it worked just fine.