Intro
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 :
Installed apps
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 .
Web apps
- Apps Scripts deployed within Google Cloud (JavaScript application whereas your application is divided into : a) Front-End on your machine & b) the Back-end on Google Cloud , idiomatically said – within Apps Script service environment [see this hotspot.js as for practical example])
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)
To recap
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 :
| Default | vs. | Standard |
|---|---|---|
| 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) |
Final notes
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 .
In case you'd be concerned..:
Please support my bug issued on Drive API for Node.js
References
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 !
Top comments (0)