Feature request OAPIF: support for API-keys via query for API implementing OGC API - Features

[heidivanparys]

Feature description.
When adding a service that implements OGC API - Features and that needs an API key for authorization of retrieving anything below /collections, the API key is stripped of the URL when the provider looks for a specific collection, resulting in a 403 error when that collection is secured. It would be great if the API key parameter would not be stripped off.

Additional context
OGC API - Features service with an API that could look like this (API key needed for all the paths that go deeper than /collections).

(see also http://spec.openapis.org/oas/v3.0.3#securitySchemeObject and http://spec.openapis.org/oas/v3.0.3#non-oauth2-security-requirement)

Even when adding ?api-key=myApiKey to the landing page URL, trying to add the features of a collection like that results in

WARNING Download of collection description failed: Error transferring https://link.to.com/v2/data/collections/collectionId - server replied: Forbidden

The log that appears in the Debugging/Development Tools:

So the API key parameter is still present when retrieving the API description but it stripped off for the next request, to /collections/station.

QGIS version

QGIS version	3.15.0-Master	QGIS code revision	0bd81d2
Compiled against Qt	5.11.2	Running against Qt	5.11.2
Compiled against GDAL/OGR	3.2.0dev	Running against GDAL/OGR	3.2.0dev
Compiled against GEOS	3.8.1-CAPI-1.13.3	Running against GEOS	3.8.1-CAPI-1.13.3
Compiled against SQLite	3.29.0	Running against SQLite	3.29.0
PostgreSQL Client Version	11.5	SpatiaLite Version	4.3.0
QWT Version	6.1.3	QScintilla2 Version	2.10.8
Compiled against PROJ	7.2.0	Running against PROJ	Rel. 7.2.0, November 1st, 2020
OS Version	Windows 10 (10.0)	This copy of QGIS writes debugging output.
Active python plugins	db_manager; MetaSearch; processing

[gioman]

@heidivanparys seems more like a bug(?).

[heidivanparys]

@heidivanparys seems more like a bug(?).

I guess it could be categorised as a bug as well, yes. I'm not sure what the rules are, recently I created issue #38382 and categorised it as a bug and it was changed to a feature request 😃 .

I haven't been able to find documentation on what security schemes QGIS supports (server nor client side), but if QGIS doesn't claim to support API keys in the query it is a feature request, if QGIS does claim to support API keys it is a bug.

[gioman]

I haven't been able to find documentation on what security schemes QGIS supports (server nor client side),

@heidivanparys
https://docs.qgis.org/3.10/en/docs/user_manual/auth_system/index.html

[heidivanparys]

@gioman Thanks for the link. I meant (but didn't write, sorry) specifically in relation to OGC API - Features.

From http://spec.openapis.org/oas/v3.0.3#security-scheme-object:

Supported schemes are HTTP authentication, an API key (either as a header, a cookie parameter or as a query parameter), OAuth2’s common flows (implicit, password, client credentials and authorization code) as defined in [RFC6749], and OpenID Connect Discovery.

So when putting that next to

I think the situation is like this (please correct me if I'm wrong!):

1. HTTP authentication: ✔️
2. API key
   a. header: ❌
   b. cookie: ❌
   c. query parameter: ❓ not working, bug or feature request?
3. OAuth2: ✔️
4. OpenID Connect Discovery: ❌