spec/iceberg-rest-catalog-open-api.yaml [175:227]:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  /v1/oauth/tokens:

    post:
      tags:
        - OAuth2 API
      summary: Get a token using an OAuth2 flow (DEPRECATED for REMOVAL)
      deprecated: true
      operationId: getToken
      description:
        The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_ recommended to
        implement this endpoint, unless you are fully aware of the potential security implications.

        All clients are encouraged to explicitly set the configuration property `oauth2-server-uri`
        to the correct OAuth endpoint.

        Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be removed from
        this spec in Iceberg (Java) 2.0.

        See [Security improvements in the Iceberg REST specification](https://github.com/apache/iceberg/issues/10537)


        Exchange credentials for a token using the OAuth2 client credentials flow or token exchange.


        This endpoint is used for three purposes -

        1. To exchange client credentials (client ID and secret) for an access token
        This uses the client credentials flow.

        2. To exchange a client token and an identity token for a more specific access token
        This uses the token exchange flow.

        3. To exchange an access token for one with the same claims and a refreshed expiration period
        This uses the token exchange flow.


        For example, a catalog client may be configured with client credentials from the OAuth2
        Authorization flow. This client would exchange its client ID and secret for an access token
        using the client credentials request with this endpoint (1). Subsequent requests would then
        use that access token.


        Some clients may also handle sessions that have additional user context. These clients would
        use the token exchange flow to exchange a user token (the "subject" token) from the session
        for a more specific access token for that user, using the catalog's access token as the
        "actor" token (2). The user ID token is the "subject" token and can be any token type
        allowed by the OAuth2 token exchange flow, including a unsecured JWT token with a sub claim.
        This request should use the catalog's bearer token in the "Authorization" header.


        Clients may also use the token exchange flow to refresh a token that is about to expire by
        sending a token exchange request (3). The request's "subject" token should be the expiring
        token. This request should use the subject token in the "Authorization" header.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



spec/polaris-catalog-apis/oauth-tokens-api.yaml [28:80]:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  /v1/oauth/tokens:

    post:
      tags:
        - OAuth2 API
      summary: Get a token using an OAuth2 flow (DEPRECATED for REMOVAL)
      deprecated: true
      operationId: getToken
      description:
        The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_ recommended to
        implement this endpoint, unless you are fully aware of the potential security implications.

        All clients are encouraged to explicitly set the configuration property `oauth2-server-uri`
        to the correct OAuth endpoint.

        Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be removed from
        this spec in Iceberg (Java) 2.0.

        See [Security improvements in the Iceberg REST specification](https://github.com/apache/iceberg/issues/10537)


        Exchange credentials for a token using the OAuth2 client credentials flow or token exchange.


        This endpoint is used for three purposes -

        1. To exchange client credentials (client ID and secret) for an access token
        This uses the client credentials flow.

        2. To exchange a client token and an identity token for a more specific access token
        This uses the token exchange flow.

        3. To exchange an access token for one with the same claims and a refreshed expiration period
        This uses the token exchange flow.


        For example, a catalog client may be configured with client credentials from the OAuth2
        Authorization flow. This client would exchange its client ID and secret for an access token
        using the client credentials request with this endpoint (1). Subsequent requests would then
        use that access token.


        Some clients may also handle sessions that have additional user context. These clients would
        use the token exchange flow to exchange a user token (the "subject" token) from the session
        for a more specific access token for that user, using the catalog's access token as the
        "actor" token (2). The user ID token is the "subject" token and can be any token type
        allowed by the OAuth2 token exchange flow, including a unsecured JWT token with a sub claim.
        This request should use the catalog's bearer token in the "Authorization" header.


        Clients may also use the token exchange flow to refresh a token that is about to expire by
        sending a token exchange request (3). The request's "subject" token should be the expiring
        token. This request should use the subject token in the "Authorization" header.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



