I cannot change users in bigrquery

Question

I am trying to access data in big query via R and bigrquery from two google accounts. The first is a work account that maps to a google account. I am trying to switch account to test the governance of the data...

If I get tokens via bq_auth Notice that the token claims to be my work address:

> bq_auth(email="[email protected]")
> bq_has_token()
[1] TRUE
> bq_user()
[1] "[email protected]"
> bq_deauth()
> bq_has_token()
[1] FALSE
> bq_auth(email = "[email protected]")
> bq_has_token()
[1] TRUE
> bq_user()
[1] "[email protected]"
> bq_deauth()
> bq_has_token()
[1] FALSE
> bq_user()
NULL

This works:

tkn2 = gargle::token_fetch(email="[email protected]")
> bq_user()
[1] "[email protected]"

Can someone explain what I am doing wrong with bq_auth()? I've tried bq_auth(email=NA) and it does not take me to a new oauth window in the browser.

here is my sessionInfo:

R version 4.3.0 (2023-04-21)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS 14.3

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/New_York
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] bigrquery_1.4.2 lubridate_1.9.2 forcats_1.0.0   stringr_1.5.0   dplyr_1.1.3     purrr_1.0.1     readr_2.1.4    
 [8] tidyr_1.3.0     tibble_3.2.1    ggplot2_3.4.2   tidyverse_2.0.0 devtools_2.4.5  usethis_2.2.0  

loaded via a namespace (and not attached):
 [1] gtable_0.3.3      xfun_0.39         htmlwidgets_1.6.2 remotes_2.4.2     processx_3.8.1    gargle_1.5.0     
 [7] callr_3.7.3       tzdb_0.4.0        vctrs_0.6.4       tools_4.3.0       ps_1.7.5          generics_0.1.3   
[13] curl_5.1.0        parallel_4.3.0    fansi_1.0.4       pkgconfig_2.0.3   dbplyr_2.4.0      assertthat_0.2.1 
[19] readxl_1.4.2      lifecycle_1.0.3   compiler_4.3.0    munsell_0.5.0     httpuv_1.6.11     htmltools_0.5.5  
[25] yaml_2.3.7        later_1.3.1       pillar_1.9.0      crayon_1.5.2      urlchecker_1.0.1  ellipsis_0.3.2   
[31] openssl_2.0.6     cachem_1.0.8      sessioninfo_1.2.2 mime_0.12         tidyselect_1.2.0  digest_0.6.33    
[37] stringi_1.7.12    fastmap_1.1.1     grid_4.3.0        archive_1.1.5     colorspace_2.1-0  cli_3.6.1        
[43] magrittr_2.0.3    pkgbuild_1.4.1    utf8_1.2.3        withr_2.5.0       rappdirs_0.3.3    prettyunits_1.1.1
[49] scales_1.2.1      promises_1.2.0.1  bit64_4.0.5       timechange_0.2.0  rmarkdown_2.22    httr_1.4.6       
[55] bit_4.0.5         cellranger_1.1.0  askpass_1.1       hms_1.1.3         memoise_2.0.1     shiny_1.7.4      
[61] evaluate_0.21     knitr_1.43        miniUI_0.1.1.1    profvis_0.3.8     rlang_1.1.1       Rcpp_1.0.10      
[67] DBI_1.1.3         xtable_1.8-4      glue_1.6.2        pkgload_1.3.2     vroom_1.6.3       rstudioapi_0.14  
[73] jsonlite_1.8.5    R6_2.5.1          fs_1.6.2   

Odd, I think this might have to do with this:

cred0 <- gargle::token_fetch(email = "[email protected]")
cred1 <- gargle::token_fetch(email = "[email protected]",scopes = c("https://www.googleapis.com/auth/bigquery", "https://www.googleapis.com/auth/cloud-platform"))

> gargle::token_userinfo(cred0)$email
[1] "[email protected]"
> gargle::token_userinfo(cred1)$email
[1] "[email protected]"

Answer 1

It took awhile to figure this out. Following direction on Troubleshooting gargle auth I set gargle verbosity to debug

op <- options(gargle_verbosity = "debug")

and tried bq_auth(email="[email protected]") deep in the verbose output I saw

trying `credentials_app_default()`
file exists at ADC path:
/Users/me/.config/gcloud/application_default_credentials.json
ADC cred type: "authorized_user"

It appears that my gargle is using my gcloud application default instead of using the email. So this is a feature, not a bug. I'm not sure why token_fetch works differently if you supply a scope. More digging is required.