How to detect whether someone has the required privileges?

[m-mohr]

From the conformance class https://api.stacspec.org/v1.0.0/ogcapi-features/extensions/transaction I can detect whether a server generally supports transactions.

What I can't detect is, whether the user (can be unauthenticated or authenticated), has permission to actually submit transactions.
In a UI, I'd like to only show a button to edit the file whenever I can be sure that the user has the actual permissions to use the transaction endpoints. This extension doesn't seem to describe this. How can we help with this?

[m-mohr]

Is it https://docs.ogc.org/DRAFTS/20-002.html#options maybe? But that would require an additional HTTP request.
I'm not sure whether sending Authorization headers or similar are well supported for the OPTIONS method?

[alukach]

@m-mohr, have you considered pushing this responsibility towards the OpenAPI specification? Beyond just describing permitted methods and expected payloads for a given endpoint, it also supports describing auth requirements and privileges via scopes.

[m-mohr]

@alukach Yes, but reading an OpenAPI is heavy and rather complex (at least from a web UI perspective), so is not ideal.
We also have the STAC Auth Extension, which is based on OpenAPI, but is more fine-grained and easier to consume via links.
But I think the transaction extension doesn't add any links to the landing page, so that might be a dead end, too.
The OpenAPI solution is also only tailored for OIDC and OAuth, but not everyone may implement that solution.
I'm also not sure how the scopes would tell me whether a user has access or not unless we define a common set of scopes, I guess?!

[alukach]

Yes, but reading an OpenAPI is heavy and rather complex (at least from a web UI perspective), so is not ideal.

The Swagger UI does precisely this, so it isn't an insurmountable task.

The OpenAPI solution is also only tailored for OIDC and OAuth, but not everyone may implement that solution.

The OpenAPI Auth docs states:

OpenAPI 3.0 lets you describe APIs protected using the following security schemes:

• HTTP authentication schemes (they use the Authorization header):
  • Basic
  • Bearer
  • other HTTP schemes as defined by RFC 7235 and HTTP Authentication Scheme Registry
• API keys in headers, query string or cookies
  • Cookie authentication
• OAuth 2
• OpenID Connect Discovery

Are there other schemes that you're interested in supporting?

I'm also not sure how the scopes would tell me whether a user has access or not unless we define a common set of scopes, I guess?!

I don't think a common set of scopes would be necessary. Rather, I would expect it to be a task of reviewing a user's scopes (e.g., parsing the scopes claim of an auth token) and comparing it to the scopes required by a particular endpoint. When building UI components, each component would compare its required endpoints/methods against the OpenAPI spec and auth claims and determine if it were to be visible. Here's a crude example: https://codesandbox.io/p/sandbox/openapi-ui-98lymd

[m-mohr]

The Swagger UI does precisely this, so it isn't an insurmountable task.

Sure, not impossible, but needs yet another dependency to read OpenAPI (3.0, 3.1, 3.x?), potentially a YAML parser, and you need to load the whole OpenAPI, which sometimes is like a megabyte. That adds quite some weight to the initial load. (Focussing on JS/web in my case, but probably also in yours?)

OpenAPI 3.0 lets you describe APIs protected using the following security schemes:

As per the OpenAPI docs 3.0, flows (which contains the scopes property) are both only supported for type oauth2.
So I'm not sure how you got to the conclusion that you can use the scopes for the other methods that you are listing. Can you clarify? @alukach

I don't think a common set of scopes would be necessary. Rather, I would expect it to be a task of reviewing a user's scopes (e.g., parsing the scopes claim of an auth token) and comparing it to the scopes required by a particular endpoint.

This could work, indeed. But it assume the usage of JWT, right? Not all implementations implement this though so you may not get to the scopes of a user (e.g. all openEO-based implementations.)

[alukach]

you need to load the whole OpenAPI, which sometimes is like a megabyte. That adds quite some weight to the initial load. (Focussing on JS/web in my case, but probably also in yours?)

Yeah, my work is primarily in web. You're not wrong that OpenAPI spec can be large, but I've found that the general support for compression via the accept-encoding header¹ in modern browser environments makes this a pretty solvable problem as JSON compresses decently well.

As per the OpenAPI docs 3.0, flows (which contains the scopes property) are both only supported for type oauth2. So I'm not sure how you got to the conclusion that you can use the scopes for the other methods that you are listing. Can you clarify?

This is a fair point. You're correct that it's not always possible to immediately know what scopes a user will have when operating with an opaque API key / session token / username + password / etc. I think it would be preferable to pursue a solution to rectify that shortcoming (e.g. an endpoint that responds to an authenticated request with that users permissions in the form a scopes) to bring user permissions awareness up to a level where we would be able to make use of an existing strategy (e.g. OpenAPI + scopes).

Footnotes

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding ↩

[m-mohr]

What are your thoughts about the STAC Authentication Extension?

[alukach]

What are your thoughts about the STAC Authentication Extension?

I'm only familiar with it via reviewing the spec; I have never tried to implement it in an API or use it in a client. I would be interested to see examples of catalogs or clients that make use of the extension. It appears to be a great way to address the varied needs around auth, particularly for asset access.

A bit off topic, but I'm currently working on https://github.com/developmentseed/stac-auth-proxy/ and hope to integrate it with the extension (developmentseed/stac-auth-proxy#35) in the near future. I welcome any input you may have!

[m-mohr]

Server: https://stac.dataspace.copernicus.eu/v1 implements the auth extension for assets.
Client: STAC Browser implements some of the mechanisms.

Currently I see it primarily used for assets, but it is also specified for links.
The question is how we could use it for STAC links (child, item, parent, data, etc.) without making it too repetitive. Maybe we should add a way to expose it somehow through the root catalog for all STAC links. On the other hand, you may not always enter through the landing page. To be discussed :-)

[m-mohr]

Relevant discussion: opengeospatial/ogcapi-features#1005