Desktop client authentication fails when not authenticated in browser

When user_saml is enabled, the login flow for the Desktop client v3.0.x fails when first trying to get access to an user account in the browser.

Steps to reproduce

1. Delete all accounts from the Desktop client, then hard close the Desktop client and start the client.
2. You should get the login wizard. Fill in your server URL and go to the next step.
3. This should open a browser screen, which asks you to login, then a button to grant the Desktop client access to the account.

Expected behaviour

You should only need to login once in the web brower + authorize the client by clicking on the button.
The client should then be authorized to have access to the account and start syncing.

Actual behaviour

The authorization procedure fails after the browser windows opens and logging in.
After logging in the following mesage is shown:

Access forbidden
Your login token is invalid or has expired

If I then leave the browser open, go back one step in the desktop client login procedure, then go to the next step, a new authorization tab opens in the browser, which then succeeds giving access.
The authorization procedure also succeeds if I'm already logged into the web interface, then follow the desktop client authorization procedure.

The difference I see in the browser network tab is as follows:
Fails:

>> request 1
POST /apps/user_saml/saml/acs HTTP/1.1
Host: xxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 9424
Origin: null
Connection: keep-alive
Upgrade-Insecure-Requests: 1

HTTP/2 421 Misdirected Request
date: Tue, 10 Nov 2020 12:26:00 GMT
server: Apache
X-Firefox-Spdy: h2

--------
>> request 2
GET /login/v2/grant?stateToken=2JEDF3y8GCI1L5qhjisvo0GWJxgrGRvfw1o3jT2Iqgh4cwounNPXzaRgqucc4iU9 HTTP/1.1
Host: xxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

HTTP/2 403 Forbidden
date: Tue, 10 Nov 2020 12:26:01 GMT
server: Apache
X-Firefox-Spdy: h2

Works:

>> request 1
GET /login/v2/grant?stateToken=n5dtwk3amDRbC993xFBVba2oUcUokUZ5LMaYTvKBh8S5fREvJ7v4RaXVRHIiLNOt HTTP/1.1
Host: xxx

HTTP/2 200 OK
date: Tue, 10 Nov 2020 12:26:25 GMT
server: Apache

Server configuration

Operating system:
Centos 7

Web server:
apache httpd 2.4

Database:
Mariadb 10.2

PHP version:
7.4

Nextcloud version: (see Nextcloud admin page)
19.0.4

Client configuration

Browser:
Firefox

Operating system:
Windows

Start by tracing the failing POST to /apps/user_saml/saml/acs and the subsequent GET to /login/v2/grant, comparing them with the successful authorization request described in the report. Investigate how the SAML login establishes the desktop client's authorization state when no browser session exists; done means a fresh browser login authorizes the Desktop client and starts syncing without retrying.