[DISCUSS] Support for authentication challenges in Iceberg REST client

[Alexandre Dutra <ad...@apache.org>]

Hi all,

I'd like to propose enhancing the AuthManager API to support HTTP
authentication challenges.

Challenges are a crucial part of HTTP authentication: WWW-Authenticate
response headers *must* be sent by the server with a 401
(Unauthorized) HTTP response. And yet, the Iceberg REST client
currently ignores them, and surfaces the 401 response as an error to
the caller.

This enhancement is important because authentication failures can
occur at any moment. For example, an OAuth2 token that was valid at
the time of the request might be manually revoked by the authorization
server by the time the server processes the request, resulting in a
401 response.

I think we could introduce a mechanism in the AuthSession interface to
give it a chance to process the challenge, and maybe re-authenticate
the client if possible. (What "re-authenticate" means depends on the
auth scheme being used – it may not be always possible).

If there's interest in this idea, I'm happy to provide an
implementation for OAuth2.

(Please note: This proposal is separate from the OAuth2 AuthManager
donation / enhancements discussed in another email thread.)

Thanks,
Alex

Re: [DISCUSS] Support for authentication challenges in Iceberg REST client

[Alexandre Dutra <ad...@apache.org>]

Hello everyone,

Thank you for the good discussion on HTTP auth challenges last
Wednesday during the catalog sync.

As promised, here is an implementation proposal:

https://github.com/apache/iceberg/pull/14241

Let me know what you think!

Thanks,
Alex

On Wed, Oct 1, 2025 at 4:20 PM Alexandre Dutra <ad...@apache.org> wrote:
>
> Hi all,
>
> I'd like to propose enhancing the AuthManager API to support HTTP
> authentication challenges.
>
> Challenges are a crucial part of HTTP authentication: WWW-Authenticate
> response headers *must* be sent by the server with a 401
> (Unauthorized) HTTP response. And yet, the Iceberg REST client
> currently ignores them, and surfaces the 401 response as an error to
> the caller.
>
> This enhancement is important because authentication failures can
> occur at any moment. For example, an OAuth2 token that was valid at
> the time of the request might be manually revoked by the authorization
> server by the time the server processes the request, resulting in a
> 401 response.
>
> I think we could introduce a mechanism in the AuthSession interface to
> give it a chance to process the challenge, and maybe re-authenticate
> the client if possible. (What "re-authenticate" means depends on the
> auth scheme being used – it may not be always possible).
>
> If there's interest in this idea, I'm happy to provide an
> implementation for OAuth2.
>
> (Please note: This proposal is separate from the OAuth2 AuthManager
> donation / enhancements discussed in another email thread.)
>
> Thanks,
> Alex