Authentication for CDSE asset download - considerations of possibilities

[MathewNWSH]

Hello,

I created demo STAC catalogue exposing 10 sample products of sentinel-2-l1, it can be found here:
https://pgstac.demo.cloudferro.com/collections/sentinel-2-l1c/items

as a way of providing access to items for users I'm using two ways:

1. the default one: using url user can access the data via zipper, here's the examples:
   https://zipper.dataspace.copernicus.eu/odata/v1/Products(189453d2-6d5a-4a62-a8ed-75cf5c494051)/$value
   and
   https://zipper.dataspace.copernicus.eu/odata/v1/Products(189453d2-6d5a-4a62-a8ed-75cf5c494051)/Nodes(S2B_MSIL1C_20240130T182609_N0510_R127_T12TUT_20240130T202802.SAFE)/Nodes(GRANULE)/Nodes(L1C_T12TUT_A036046_20240130T183024)/Nodes(IMG_DATA)/Nodes(T12TUT_20240130T182609_B01.jp2)/$value%22
2. alternative one: using s3 protocol (this way is not a subject of this issue)

here's the instruction on how to download data from zipper:
https://documentation.dataspace.copernicus.eu/APIs/OData.html#product-download

basically to download the data user has to:

1. get the access token:

curl --location --request POST 'https://identity.dataspace.copernicus.eu/auth/realms/CDSE/protocol/openid-connect/token'   --header 'Content-Type: application/x-www-form-urlencoded'   --data-urlencode 'grant_type=password'   --data-urlencode 'username=***'   --data-urlencode 'password=***'   --data-urlencode 'client_id=cdse-public'

2. export the access token to envriomental variable:

export ACCESS_TOKEN="..."

3. make a request to download the data:

curl -H "Authorization: Bearer $ACCESS_TOKEN" 'https://catalogue.dataspace.copernicus.eu/odata/v1/Products(060882f4-0a34-5f14-8e25-6876e4470b0d)/$value' --location-trusted --output /tmp/product.zip

What I want to achieve?

When a user accesses the STAC via a browser and clicks on the asset's "zipper" URL, the communication returned is as follows:

What I'm aiming for is to facilitate browser access so that users can freely access the data in the most optimal manner, which I believe is achieved simply by clicking the URL (after creating an account) without the need for using the terminal.

After reviewing the extension documentation as well as the CDSE documentation, I added the following to my STAC items:

    "auth:schemes": {
      "oauth": {
        "type": "oauth2",
        "decription": "requires a login and user token",
        "flows": {
          "authorizationCode": {
            "authorizationUrl": "https://identity.dataspace.copernicus.eu/auth/realms/CDSE/protocol/openid-connect/auth",
            "tokenURL": "https://identity.dataspace.copernicus.eu/auth/realms/CDSE/protocol/openid-connect/token",
            "scopes": {
              "read:example": "Read the example data"
            }
          }
        }
      }
    }
    
#and on the asset level for B01 asset:
      "auth:refs": [
        "oauth"
      ],

This is how it's being exposed in STAC Browser:
(url to discussed item:https://radiantearth.github.io/stac-browser/#/external/pgstac.demo.cloudferro.com/collections/sentinel-2-l1c/items/S2B_MSIL1C_20240130T182609_N0510_R127_T12TUS_20240130T202802?.asset=asset-Product)

PS. I also tried requesting the data via zipper after logging to my CDSE account, but the same communicate is revived. Token is the must.

PS.2 Please feel free to play with my STAC catalogue, I'm trying to make it the most user friendly there is. In future I would love to populate it with complete L1C and L2A Sentinel-2 collections.

Can it be done with support of authentication extension?

[m-mohr]

I guess the main issue here is that STAC Browser doesn't support the Auth extension yet.
Related issue: radiantearth/stac-browser#81

[jamesfisher-geo]

Yup. @MathewNWSH what you have looks good. However, like @m-mohr said, afaik there is not a front-end implementation of the Authentication extension.

Creating a STAC API of Planetary Computer data to develop an implementation on has been on my to-do list for awhile...

[m-mohr]

I think we can close this, STAC Browser has a proof of concept in radiantearth/stac-browser#304 (openIdConnect + apiKey only)

[StijnCaerts]

Another question related to this issue: how would you provide the client_id information for OAuth2/OIDC using the authentication extension?

proof of concept in radiantearth/stac-browser#304

I see in this example code snippet that you list the client ID in oidcOptions.clientId field, however that's not explicitly part of the authentication extension. Should such a standardised field be added to this extension? Or can we reuse the parameters field for supplying these extra parameters?

[m-mohr]

@StijnCaerts Well, the issue is that client IDs are rarely generic enough for all clients. As such you can't embed them into the STAC items, at least for web clients. You'd need a specific deployment of STAC Browser which supplies the client ID as part of the authConfig object. In a web context the auth extension is not overly useful due to the redirect_url issue...

[StijnCaerts]

@m-mohr, thanks for your response! My question is not limited to the STAC Browser, but also other tools like stac-asset. We would like to add support for OIDC/OAuth2 to the stac-asset tool: stac-utils/stac-asset#143

But even then we can still require the user to enter the client_id instead of automatically loading it from the STAC Item.

[m-mohr]

The question here is probably whether a client ID is persistent enough to be added to the STAC metadata. You may need to update all items if you need to change the client ID.

Generally, it's difficult with OIDC having these many-to-many relationship between clients and servers, ask e.g. your VITO colleagues working on openEO ;-) I'd propose to open a separate issue here to discuss the client ID issue specifically. @StijnCaerts