how to tell if a data center requires token access

[crotwell]

Would be helpful if the data center registry was updated to allow clients to programmatically determine if anonymous requests are allowed, and if not what identity providers are trusted for each data center.

[jschaeff]

Another complementary approach would be to specify way for a user to check the possibility of token authentication.

It could be a HTTP HEAD request that would reply in the headers all useful information manage-token: true, trusted-token-providers: [list]
This could be scrapped by the FDSN datacenter registry.

[crotwell]

Conern that using HTTP headers to return this info is somewhat opaque to normal users.

[crotwell]

Perhaps spec should just say that data centers should document if they require/accept token based auth and how to acquire a token if needed. I've added a line to issue #1 saying this.

Then, if this spec is approved, we can add an issue to the datacenter-registry repo to add token supported/required/unsupported to each datacenter registry entry.

[rcasey-earthscope]

It looks like we might have an RFC standard we can follow.

https://workos.com/blog/introducing-rfc-9728-say-hello-to-standardized-oauth-2-0-resource-metadata

I saw examples show up elsewhere on searches that indicate Azure is ahead of the game on this in that they provide rich responses on their 401 WWW-Authenticate returns, and now this approach has been published this spring.

We have also dabbled with the .well_known endpoint for some of EarthScope's API development relating to OAuth, though I forget if it related to this RFC or some other form of metadata.

At minimum, the client test to check if an endpoint requires token access is simply to get a 401. What is nice about having metadata come back in the return is that the client can then automatically adapt.

[crotwell]

Would the client get a 401 if they specify a request using wildcards that matches some restricted and some non-restricted data, like in dataselect?

See #2

[rcasey-earthscope]

Hi Philip-

That is a very good question. I think the first answer would be that this would be data center dependent. My second answer can perhaps explain the first point.

At IRIS, traditionally, we had two endpoints, one of which was explicitly for authenticated access. While not being OAuth2 in nature, the auth endpoint nonetheless followed the same 401 challenge when contact was initially made. Our rule for accepting mixed requests on the non-authenticated endpoint is to filter out any restricted datasets from being processed, but in answer to your question, there will always be a 401 challenge on an endpoint using Digest authentication.

As EarthScope, as we transition to being an auth-only service center, we will endeavor to pilot OAuth2 into our service stack, even as we must continue to support Digest auth for the foreseeable future. Unlike with Digest auth, an OAuth2 endpoint will not return a 401 on first contact if the client presents a valid access token. The client will only receive a 401 if the credentials are missing, expired, or malformed.

The above will occur regardless of the payload of the data request itself. Beyond that, since our services do tend to filter to a mix of resources with varying permissions, EarthScope will in all likelihood filter out non-authorized content from being delivered to the user. This tends to be an opaque operation with no return messaging to the use about what was filtered. I don't know if we're going to change that aspect of content filtering in the future.

Another data center might decide that it's all or nothing, in that a single misfit to authorized access results in a 403 Forbidden for the entire transaction. I don't know if the FDSN will want to push for those kind of handling rules, standardizing the business logic outcomes.

[javiquinte]

This is a very good point. I never had thought about it, as the header can be completely ignored, but you are totally right.
Considering the specifications that we already have for the different WS and the use of the application.wadl endpoint (not that I like it at all, but it's our standard) we should follow the section "2.9 Request" of the standard and include the header "Authorization" in the WADL declaration for the "query" method.
That respects the approach used by software like Obspy, that makes use of this WADL file to check which services a data centre supports.

[jschaeff]

Good idea to use the WADL file.