Closed h-michael closed 9 months ago
The former has a little too much influence, so I implement a new struct InternalIdToken for now.
I agree with the current implementation, as it is easier to understand if different fields are received in the response if they are explicitly separated.
Thank you for your great work! I implemented generating ID token function with service account credentials.
Implement
IdTokenSourceConfig::new
IdTokenSourceConfig
's all fields are private. So There is no way to build IdTokenSourceConfig.Implement
InternalIdToken
to deserialize ID token responseID token endpoint's JSON response is the following schema.
This doesn't include
access_token
,token_type
andexpires_in
. Therefore, if I try to deserialize it asInternalToken
, I get an error.I know
google-cloud-rust
follows Google Cloud Go. So I looked into how it is implemented in Google Cloud Go. I found a function below. https://github.com/golang/oauth2/blob/950ef44c6e079baf075030377d90bf0c7e4b7b7a/jwt/jwt.go#L101-L185 If the expected key is not in the JSON payload, Golang sets zero value to the key so that no error occurs when unmarshalling.To avoid this with Rust we need to make
InternalToken.access_token
andInternalToken.token_type
toOption<String>
or need to implement another struct for deserializing ID token response. The former has a little too much influence, so I implement a new structInternalIdToken
for now.Which implementation method would you prefer or do you have another idea?