nika-qubit commented on PR #12362:
URL: https://github.com/apache/iceberg/pull/12362#issuecomment-2675313630
@adutra Thanks for the detailed explanation.
A little background of why I was adding the refresh token flow:
I'm trying to make the auth package work with Google OAuth 2.0. Since the
client is not the (cloud) resource owner initially, a user consent is always
needed from the very beginning.
1. The user consent gets you an authorization code. (This is the only place
where a user interaction is needed).
1. Then your (default) application can use the authorization code to
exchange for an access code through the authorization_code grant type (this
additionally requires the client id and secret in the request and returns a
long-living refresh token along the access token).
1. Then your application can either continuously use the previous step or a
refresh token flow to get new access tokens.
Based on my knowledge, Google OAuth 2.0 does not support the
`client_credentials` grant type (nor the `token_exchange` grant type but some
other auth API endpoint may do).
From my perspective, both point 2 ("authorization code flow") and point 3
("refresh token flow") send requests to the auth server with the client
credential info with each of their own additional code/token without user
interaction.
Do you think I should start looking for Google's auth endpoints that do
support the "token_exchange" grant type?
A side question is that an access token usually expires in an hour. Does it
mean if we set the option, the REST client can only work for that amount of
time?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
