Google glass, Google assistant, Google Cloud, not mentioning Google Google Workspace offered Google Drive with its related services like Google Docs, Sheets, Slides, etc. just like people tend to say – Google is everywhere . Although Google is everything not everything is perfect & that's the documentation they provide , although I noticed they are already working on it (maybe someone's feedback on docs been worth the time) , they even published live docs on a new re-furbished PWA series check it out . I could talk and talk, although my intensions are very simple : I am building external application that will utilize some GCP provided service APIs . The problem is that documentation does not clearly define difference between Installed apps & Web Apps . Luckily a few opened issues on GitHub, not mentioning hours of patience reading on developers.google , in my opinion, averagely organized docs (at the time of writing) , I've managed to demystify the following :
Service-to-Service using service account : none of End-user (human like me & you) interactions intended , the application you build impersonates End-user maintaining only two parties . Such OAuth 2.0 flow called 2LO (two-legged flow)
Server-side within user-account : this is three-legged (3LO) OAuth 2.0 flow that encapsulates three parties i.e.: a) End-user which delegates one's consent for the client , b) the client (your application) that talks with c) Google services provided APIs on behalf of End-user's consent given .
NOTE : It can be a scenario your Web app will be required to use 3LO grant (flow) . In such scenario you would be required to switch your Default GCP Project to Standard one explicitly targeting specified Project's ID to Apps Scripts codebase (steps 2-4 to follow) .
TIP : It's good practice to switch before taking any development actions, as switching to Standard for development later may have – "side effects]" .
FINALLY : there are aplenty other reasons why to switch (read the list)
Default to Standard , including whether or not to utilize service-account may be found daunting experience, that's I made this table to conclude everything to said above :
|2LO with user-account (e.g. Web app with*out* consent screen)||...||3LO with user-account (e.g. Server-side as Web app with consent screen)|
|...||...||2LO with service-account (e.g. Service-to-Service with*out* consent screen)|
You can probably guess I've already had some basic experience with Web Apps , the answer is correct, I had ! When it came about NOT Web Apps, say Server-side application that would be exploited by other End-users (e.g. developer building application for some company), which is not a type of application (client) I am building personally , rather then that, Service-to-Service with service-account is a way to go ! Service account help you avoid End-user (human) involvement which means you don't need any consent screen configured – that's basically what 2LO flow is all about – service-account impersonates End-user on its own (managing its own data rather than End-user's) , resulting into involvement of two parties only i.e.: application (client) you building & Google's service-account as identity for protected resources .
NOTE : *currently experimenting with legacy as it provided with larger list of GCP services supported APIs
If anything to add, please leave a comment in the comment section below . Thanks & see you in the next one !