Demystifying authentication and authorization for Google Workspace developers
foreign [Music] hi everyone uh thank you for coming um it's actually the first big conference I've done in a few years and I forgot how fun it is to do these uh I also forgot how important it is to take care of feet and voices uh so good reminders I didn't do so well yesterday but hopefully uh we'll be fine for this talk a little bit about myself um Stephen basil I'm a part of the workspace developers uh relation Google Google developers relations team for workspace I've been at Google for coming up on about uh 14 years in about two weeks um so happy anniversary to me um and most of that time has been on workspace so I've been working on workspace apis before it was even called workspace uh going back to drive B1 and docs list and some apis that don't even exist anymore um and I I love talking about authentication and authorization because one of the common threads that runs through workspace apis which is a little bit different than other apis that Google is workspace data is usually owned by users it's done by users and organizations um and so getting permissions to deal with uh access to data is a little bit more complicated a little bit more frustrating sometimes than what you might see with apis like Maps or gcp Services where uh and an API key might be sufficient to do what you need but workspace isn't really my first foray into identity and access management prior to to working at Google I spent about seven years at RSA security uh had worked on identity and access management as there as well worked on some technologies that actually became the precursors to what we now know as saml and some other protocols so this is this has been a For Better or Worse a 20-year part of my career dealing with identity in some way or another and even though it's not necessarily the thing I focus on these days it's still a topic that is uh you know near and dear to my heart and you know I'm happy to answer questions um and help people um after the stock there we go um so in terms of um what to expect so I I authentication and authorization are are huge topics these are not things that we can cover comprehensively in 45 minutes uh or even a day there's entire conferences that you can go to and learn really really in-depth stuff about uh authentication or authorization um so for today uh as of the title of the talk implies this I want to take a look at authentication and authorization for workspace from the lens of a developer right so there's some uh information some data in workspace that you want to work with as a developer and how do we do that and the way we're going to do that is we're going to actually look at four uh the most common scenarios that you would encounter there's going to be some that we're going to ignore but I chose these particular four because um they're fairly representative of like the most common use cases and some of the ones that we're going to like not really pay attention to do fit into these buckets in one way or another um and what we're going to do is we're actually going to start with a really really simple problem statement um so you know hopefully really trivial and then we're going to take that application we're going to morph it add a new requirements to introduce new Concepts and new capabilities until they get to something that is um you know something going from as simple as apps script to something that you would see more in a Enterprise it use case um all the code there are some live demos all the code is available on GitHub you can feel free to uh take a look at that later if at an employee you can't read anything uh everything will be available for you to read so I want to start with a really like I said really simple problem statement um and since I spent a lot of time working on uh the drive apis I decided to pick drives it's also one of the most popular apis for workspace so we're just going to do something really simple just List the 10 most recent and by recent I mean uh most recently modified doesn't really matter for this use case um and we're gonna do that and I want to start with the easiest way I know how to do this which is with apps script and do how many people use uh apps script so about a quarter or a third of you for those who who don't use app character are maybe not aware of what it is it's a cloud-based JavaScript runtime that just has really tight integration with Google workspace and our architecture and I'm using architecture very Loosely here is we have a user it calls the script calls the drive API and that is it right this is but I say trivial I really meant trivial like this is the entirety of the application that we're going to run um and the nice thing is it actually reads very similar to the problem statement that that we set out right it's called the files list API sort them descending order for modified limit to 10 and print out the results um so you might like Wonder like they're supposed to talk about authentication and authorization authorization why is there no mention of authentication and authorization in the code right um and the reason is there's a lot of heavy lifting that apps script does when it comes to dealing with user permissions and identity and so on um and you know if you if you take a really naive look at that code right it raises a ton of questions right like whose files is it going to ask is it the person who wrote the code the person who's running it um what else could that script do right like how do we know if it's safe to run if maybe I didn't write it somebody shared it with me like I would be really worried about like just trying to understand what uh limits are actually placed on that that bit of code we'll see what it does um and then uh you know take a look underneath the covers to get a better understanding of what's actually happening [Applause] uh so this is the apps script IDE um for some of you this will be really familiar but you see the same code that we had up on the slide and I can run this code and the first thing it's going to do is actually going to ask me for permissions right so for hopefully obvious reasons we don't want so just run code that can do anything I can do right that would that would scare me a lot as a user um so we're gonna see what it's going to ask for and we'll review the permissions and here we do we have to choose the account this is so we know whose files we're actually going to be accessing who's granting the permissions and what it wants to do is do everything in my Google Drive and that that's actually a fairly broad set of permissions that I'm branding it like I have a lot of stuff in drive I don't necessarily want to share everything with a script but for that move we're going to do it keep it here and we'll talk about why this matters a little bit later on in the end but for a demo purpose like I'm fine grinding the scripts uh access and once they're done it just prints out the files just as we expected so you know in terms of those questions right like the way apps script works is yeah apps script is an authenticated environment right it's it knows who I am because I'm logged in with my Google account and every script I run needs to be granted permissions in order to read my data um the way all this works underneath the covers is using uh two standard Technologies uh that you would use in your own applications for building on any other platform and this is mainly oauth 2 and open ID and you can think of openid as just an extension of oauth 2 just focused on user identity so auth2 is gives you a way to uh for a user to Grant permissions to an application to access some of its data give grants and certain permissions open ID extends that notion to that data being their identity right what's my email address what's my profile picture my name things about me right as opposed to data that might be in my Gmail account or drive or so on but they're very related and they form the foundation of how apps script and how applications in general when you're working with workspace API is work so kind of the best way to understand this is we're going to take that same application and we're going to remove the support that apps script was giving us um so fgrip did a whole bunch of work in terms of knowing who the user was um requesting the access for us managing where all that is stored and how it's passed into the apis so we were left with a very very small amount of code if we want to do this in an environment where we don't have that we don't have that luxury of what apps script is providing we have to do a lot more work so we're going to change the statement we're going to say 10 most recent files but I want to do it as a web app that I can deploy anywhere right and this could be on Firebase or AWS or Brazil any we know picker hosting platform of choice and since apps script was is Javascript based we're going to keep this in the same family languages we'll just do this as a client-side web app so architecture is pretty similar um we have users we're going to talk to some application and that's going to talk to the drive API but we're introducing a few new components into this architecture all right so we have obviously a server apps script was sort of previously doing this for us it was our runtime environment now we need our own it's going to be a server and a browser and we need some way to recreate what apps script is doing right so we need to know uh some way to basically get permission from the user in order to access their their files in Drive and for this number we're going to work a little bit backwards I'm going to just start just going to run the code we can actually see this doing the exact same thing that apps script is doing and then we'll we'll deconstruct it a little bit and then kind of see how the the um how it all comes together uh so this is uh this code on repl again it's a pure client-side web app and if I click fetch rails we have a slightly different UI just because I had to you know Implement more of the stuff that apps script is already providing us Grant access and we're going to Grant access to read everything and drive click continue and we get our file list so exact same app in terms of functionality but we've removed apps script from the picture and recreated all of the the infrastructure it was providing and just to show you like the the kind of two important parts uh if you were to you know look at this code on GitHub a lot of this is really just UI related code it's um Simple app using lit uh which is great framework for lightweight apps but the important parts are the fetch file list we do have a JavaScript client Library decided to keep it limited to just using the fetch apis just so that the code is a little bit more verbose and a little bit more explicit about what's going on but we're doing pretty much what we were doing in apps script right so we have our our parameters to our search we're using you know modified time limiting our results to 10. calling the drive API but we're start to differ as we start introducing some new Concepts right so we have this thing called an access token right if I were to just call the drive API with no authorization header it wouldn't know really anything about that request in order to answer it right I wouldn't know whose files it's listed in which application or anything so we need some way to communicate that information about the user and the application and what it's allowed to do and the way we do that is via this access token and the rest of the rest of the code is just error handling and response parsing so the question is where do you get this access token from element the simple answer is we ask for what to do this this code is using the Google identity Services SDK for JavaScript this is a relatively new library in the last couple years it actually makes you getting all off tokens or access tokens pretty much as simple as you can make it handles a lot of the plumbing with the UI in terms of doing pop-ups tracking whether or not the user closed it and so on so really the only bits of information that we need to provide are something called a client ID and this is what identifies our application and we have to describe what data we actually want access to right that's and that this would be a mechanism we call Scopes so in this case I'm just saying I want read-only access to everything in Drive um once we do that we have a callback so once the user you know gives us consent we get a what we call a Nexus token we get back an expiration time Google access tokens are limited to one hour and they will actually expire unfortunately the expiration time comes back in the number of seconds remaining uh so we have to do a little bit of date math in order to convert that into a more usable time stamp that we can check later on um knowing you know one hour in the future at any point is not really useful but once you do that we can return the access token and when we're ready to request we just say request access token right and that actually that causes the pop-up to appear that we saw when we ran the code up so this is a couple questions like okay well kind of get access tokens but there's a lot more to them uh and also like how you actually get the client IDs and set up all these projects and we'll switch over here I'll just talk a little bit more about those it says that like access talk is actually um they pack a lot of information into those tokens right they they're not just it's not the equivalent of a password they actually buying three three uh unique pieces of information that we need in order to answer API requests right so it's who's the application right is this um you know is this Asana is this uh Miro or you know lucidchart or something a script that somebody wrote we didn't know who the user is the subject um sometimes you'll see a subject or principle there's a few different terminologies you'll see when you're looking at authorization Docs uh but this is basically who is the user that this is bound to right so when I authorized um that created you know this permission for this application to run on my behalf and then the last thing we need are the Scopes and these are the things that say like what are we constraining this application to do um and also like I often refer to oauth as not necessarily an authorization protocol but a delegation protocol because the the permissions that I'm granting to the app are a subset of the things I can do I can never Grant the application any more access than what I I naturally have and my natural permissions are going to change over time independent of when I authorize that app right so it's always going to be like what is the current set of files that I have access to as opposed to a snapshot of the files at any given point in time uh so these are access tokens these are the the magic keys they're they're also considered with uh Bearer tokens right so which means if you have one of these access tokens you are affected like you can call those apis you don't need any other proof of that you are authorized other than that string that you can pass in an authorization editor it's one of the reasons why they are time limited just an hour because they are very powerful uh things to happen so you always want to make sure that they're transferred over secure channels all the apis only except uh TLS encrypted traffic and you just want to make sure that you're not leaking these in ways that um things like uh put them in like query parameters or things that might leak in logs or proxies or anything like that so in order to actually make all these requests we've talked about a client ID and so how do you get one of these clandities well you starts with Cloud projects um and for those of you who are in uh kind of the app script world if if you've only ever done apps script you might never have done this but Apps scripts has done it for you um every time there's a new script created apps script will actually create a gcp project it will turn on a whole bunch of apis uh fill out a hole in for a bunch of information about your application uh create client IDs and it does that automatically every time for every script that you create so every script is its own unique little isolated application there are times in apps script or you might want to do this manually or if you're doing without ask script again you also have to do all this manually but the three things that we care about for workspace is turning on apis right this is just a signal for quota enforcement uh things like that just we know which apis your project is using fine EDS you can think of these as the credentials for your application they think of it it's like a user a username and a password for your app uh and then the consent screen is branding information for when we ask the user for permission it's how you signal uh to the user who your app is and why they should trust you all right so it includes things like your icon your app name uh contact information but also things like your terms of service and your privacy policies and if you're just building something for yourself or you're building something for your own organization obviously a lot of that doesn't really matter right like do you care about your own terms of services are no right it's just your code you're going to run it but if you're if you're bumbling if you're a software vendor and you're building an app for commercial purposes you're going to have customers then this stuff starts to matter and we'll talk a little bit more about what that why it matters towards the end and so I said you know earlier we kind of looked at this where it's kind of like like go back to the beginning of that process of like how you would actually build the app that we started with in apps script from scratch if you were doing it in a different environment and so it starts with creating a project doing your consent screens creating your client ID turning on your apis writing your code for oauth calling your apis and you're done right and then you have a functioning app and you're working with like workspace data whichever API if it's drive or Gmail or calendar it doesn't really matter um and the kind of the awesome stuff with apps script is you get to jump to the front of the line right like you're you're skipping you know almost every step and you're just going to write code and done um so I love apps script for that this doesn't mean you should all just like jump on apps script and use it for everything it has its limits um but for just quick and dirty like I just need to do something with my data and automate something it is a really wonderful solution that saves a ton a certain imaginable unimaginable amount of time all right so one of the limit the limitations of of that version of the app is the the the flow that we use to get the access token was actually something called the implicit flow uh and it's really really great if you just want an access token right away uh but the problem is that that application only works when the user is using the application and for a lot of use cases that's totally fine if you're doing um suggesting content to link to a project right and you just want to show hey here's the most recent files that you might want to uh right create a link for right totally makes sense to do it in a way where you don't need anything more than a short-lived temporary access but there's a lot of other cases where that's not enough right you're doing batch processing uh auditing compliance backups there's a whole a whole world of use cases where you need to be able to access that data anytime day or night for long periods of time um without having to have the user interact so there's a different flow and a different mechanism in a wallet where we can we can ask for long-term access and so we're gonna we're gonna change that we're going to change our use case to say well we're gonna instead of just going to an app and printing out the list I want to get an email report and in this code we didn't actually implement the email reports because I don't want to you know demoing let's wait till Thursday at midnight to get an email it doesn't make for a great demo so it's going to be the same UI but we're going to change the structure of the app and the code to mirror what we would do if we need this sort of offline batch processing so this is our updated architecture it's pretty similar the main difference is we're adding a back end right so we need to run code in some secure environment somewhere where the user is not going to be involved um and because we're going to start storing more information we need a database we need to store which users have signed up what their email address is and uh store these tokens right we need we need some you know some way that we can call those apis later on and someplace to keep them um and before we go into the code uh I just want to talk a little bit about authentication because um it's a it's a little bit of a weird topic to talk to because on one hand if all you care about is access to the workspace data it honestly doesn't really matter how you choose to authenticate your users right and you have a ton of options right like you know you can do it the way everybody's been doing for since the beginning of you know computer time and and you know write your own username and password management system and store hashes and you know have your account recovery for um I would strongly discourage anyone from doing that um I I would be very happy in for the rest of my career if I have never written another login page in my entire life it is just unnecessary and it comes with a ton of baggage from uh just a secure security perspective from an operational perspective there are much much much better options um and I'll talk about the option that I choose in this demo I'll talk about why I actually chose that um more um you know more likely what you're going to want to adopt is either a Federated approach or using um something like we call like office of service um so in the Federated approach it could be open ID it could be uh you know you can Google sign in saml if it's in more of an Enterprise use case is is pretty widely used it doesn't really matter which particular one right maybe it's even just using uh talking to your ldap server all of those are totally fine um and then if you want to just sort of offload a lot of that work uh office of service sometimes things like Firebase Cloud identity uh off xero uh Super Bass is another uh similar to Firebase in terms of functionality and these basically take that vertical slice of everything around authentication user management recovery Federation working with multiple providers and just packages it up in a way that just makes things so much easier so for this particular demo that we'll do next we do need to add authentication and because this particular application is really only designed to support your Google users I'm going to use Google sign in which is basically an open ID based approach and it's just like the least amount of code that I needed to actually solve this particular problem and that's really the only reason I chose it right if I needed more functionality I probably would have looked at something like Firebase or Cloud identity as a more robust solution to handling how I authenticate users all right so we're gonna go switch to this demo let's yeah so a slightly different experience this time right so instead of just going to straight to an authorized uh Or List files button first thing it's going to do this is actually using Google one tap um so this is automatically as soon as the user hits the page it's going to ask for like hey we see your Google user uh do you want to sign it right and it's a extremely expedited flow it doesn't share any information with the application other than basically my basic profile information and once I give it consent that code's going to sign me in it's going to create a session like we would do for just about any web app regardless of what authentication method we chose and also change the UI a little bit in this case so we have two buttons now right instead of just one button that does everything I'm going to split the authorization this is exactly the same as what we saw before the difference is the when we look at the code the actual mechanism for how this is all working is a little bit different so once you're ground we can hit fetch files and same thing as before so same application same functionality the main difference that we added this time is we added authentication so we know who the user is um and we implemented a different a different authorization flow for oauth that gives the application long-lived access so I can come back in you know come back tomorrow hit the list files and it's just gonna work I don't have to give consent again so long as I'm logged in and knows who I am and it can get my tokens like it will work and it will keep working indefinitely until me as a user decides I want to revoke access and there's ways you can do that in your uh Google account security page but now like this this can send me emails you know every day or every week whatever my schedule is and I don't have to think about it or worry about it so on the so there's a couple bits I want to take a look at um take a look at sign in so the nice thing is Google sign in and since it is based on oauth it's the exact same all the setup that we did for setting up our client ID for oauth filling out our consent screen all of that just automatically carries over it's the same quantity as the same application I don't need to do really any other additional work other than uh asking using a different method basically to say like well like can you log in the user so um where we had this like token client before we have we could say Google accounts ID prompt and that's just asking the user hey like log in this user let me know when you're done and what we get back is what we call a a jot it's a Json web token uh and what this is is just a little blob of Json that has profile information about the user uh it's signed uh verifiable and we'll take a look at that code of what that looks like but without having to know the user's password or really anything about them like the app can just get this verifiable token and then convert that into whatever credential format it needs internally right maybe you can use a jaw as a session token in this case I'm just using cookies in my own session we have a lot of different options for how this all works um the [Music] let's go with you [Applause] there we go yeah so this is basically the verification for uh when we get that job we're just gonna this is the back end code now this is not client side this is uh just a express.js uh route Handler so when a user signs in and we get that job there are some things that we have to do from a security perspective we'll talk about that in a little bit um after this um but hopefully things like like uh cross-site request forgery preventions are hopefully familiar topics uh if not we can talk about them happy to answer questions but we're just using the the this is the uh node.js off Library uh
for our API clients it actually has a built-in method for verifying the token so I don't really have to give it much other than the token itself and our client ID right and that's actually really important for uh making sure that attackers don't give us like you know don't mint their own job for their own app and like try to you know confuse who like well yeah just because I signed into that hey it doesn't mean I can sign in for app B so that's really the bare minimum of what you do the library does a lot of other checks in terms of checking expiration times checking the validity of the signature so most of the time you don't really have to get into any of the nuances of like how dots work or the encryption or uh assigning methods or anything like that just use the libraries they work great they'll do the checks and make your life just a lot easier and then once we do that we have you know we have some information so in this case it's uh subject is user ID we have the email name and and Avatar Photo from Google and we can use that to just make the app look nice for authorization very similar it's actually very similar to what we saw before and but instead of calling this in a token client we're calling it code plan and this just is an instruction to the library that we want we want a long-lived uh Grant and a Long Live token that we can use for app indefinitely the the difference in these flows like from a UI perspective almost indistinguishable right and just doing that demo you couldn't really tell which flow was was which from an implementation perspective the difference is that instead of getting an access token back that we can use immediately if we get back an intermediate value I get this uh what they call an authorization code and what we need to do with that code is then send it to our backend send it to a more secure environment where we can then turn around and exchange that for both an access token and this new type of token uh which we haven't seen yet which is called a refresh token and that refresh token is the thing that we need to save right that's the thing that we can indefinitely every time we need a new access token you need to call an API we can take that refresh token and ask Google give me an updated access token that I could use right now and there's a little bit more security around that part of the reason why you have this a little bit of an extra balance in how this is all this all works but really the code is almost the same uh we just uh as soon as we get that code we're just going to forward it to our back end and then process it there so you can actually see what that back-end code looks like it's that this exchange code method um so other than doing uh some you know request ordering protections we're just going to use the client Library just like we did before for verifying the jot we're going to give it our client ID and client secret which we get from our gcp project and then we exchange that for our tokens and then once we once you have these tokens because these are long then we want to hold on to them this is why we need our our sign in and our database we want to just make sure that we save those credentials in a way that we can you know associate them with the user in a secure way but once we've done that we're good like we can now call apis for um anytime we want for that user until our access is revoked uh and our list files method is actually pretty similar instead of um we've moved this to the back end all right so we're not running in the client anymore uh we just have um similarly we're just going to like take loader credentials from the database we're gonna check to see if our access token is expired um again these do expire every hour if it is expired we just need to call this refresh access token right and so long as we're providing in our you know valid client ID and secret and so on we can just keep doing this anytime we want once we have that you know we can it's an optimization to like re-save the credentials and re-save the updated access token uh but then after that the code for calling the drive API is exactly what we had on the client side parameters call it past the other authorization header with the token and we're done and so it's almost the same thing we just saw a slightly different way of getting those tokens um and and that's it but before we move on to like the next the the final use case um I wanted I want to talk a little bit more about uh security um and so you saw like hints of that in the code you saw some um cross-site request forgery uh protections there's a number of ways that you can go about um protecting this summer very simple some you know a little bit more uh a little bit more secure but a little bit harder to implement but when you have offline access like your app has a lot more capabilities right an access token on the client that expires in an hour if it yes it's bad if it leaks um but it's not the end of the world like that token will naturally expire and become useless you know within you know 60 Minutes you still want to protect them as best you can but a refresh token lives indefinitely all right so like if if that leaks if that and your client ID and client secret are exposed right well now now an attacker has they can do a lot more damage um and they're also that because of the differences in the protocol there's actually some really uh unique attacks that uh attackers can do with uh basically unsolicited requests right where I can take um begin the authorization process for an account I control and then trick you into completing it and Associate and linking that with your account and so most of the most of the uh the countermeasures that you see uh recommended with oauth are really around making sure that the person who requests access is the same person who you're actually like like you want to make sure there's continuity throughout that entire flood um and you know not letting people like you know start on one device complete another because those are generally going to be attacks um good news is there most they're actually really simple to implement um the majority of them are if you built a web app and you've dealt with uh prostate request forgery same defenses that you would use for protecting a form you would use for protecting your sign-in and your oauth flows uh there are some uh oauth specific mechanisms that use in specific in certain use cases for sign in uh just making sure you validate jots correctly there was actually a somewhat Infamous vulnerability that came up not too long ago um where some libraries allow it undesigned jobs by default so you can just make up anything you want um that's a pretty bad role in our ability if you can let then attacker just be any user at any time um first a lot of things are fixed and develop behaviors were pretty good and then obviously you want to protect secrets and so on uh I do have a link to uh there's an RFC on oauth security threats encounter measures again you don't have to be an expert you don't have to read through all of it but it is actually really interesting if you like security it's really interesting reading to see why the protocols work the way they do and why the recommendations are what they are but when it comes down to implementing you don't really have to do a lot you just have to make sure you do you know at least the things that are uh strongly recommended by any provider that you work with [Applause] all right so we're gonna we're gonna do one last uh variation on this and this is more for uh we're gonna get into like more of the Enterprise use case so like it's great you know we have an app users can sign up they can get their reports but now as you know somebody in it and I have to manage clients for my org I want to get you know whatever report we're generating I want to do this for every user in my work all right and well yes we could have them all go to the app and log in and sign up and give access but once you get above probably a pretty small number of users that becomes uh just impractical right and certainly if you're an oracle of thousands to descendants tens of thousands of users like it's it's not you can't even have that conversation at all right so for somebody if you're coming that's from an I.T perspective right you need a way to be able to Grant your apps uh and make these uh these decisions on behalf of all your users without having them in the picture so we're gonna have a slightly uh and we're actually a slightly simpler architecture than we had for the for the other app um kind of back to almost what it looks like with that script where we have an admin is gonna we're gonna run some script is going to talk to drive apis but the part that we're adding is this this out of band um it's not a band process between the ad you know the IC admin or you know somebody who's privileged enough to make these decisions um and then granting our app access via the uh the the Management console for Google workspace um so what this allows you to do is that and and before where we had client IDs we're going to use a slightly different mechanism that is probably more familiar if uh are there like people who use gcp okay so probably like have dealt with service counts right like so you have service accounts and that's kind of the primary way for uh for gcp to use uh to do authentication right and it's just identifying who your application is very similar to what we use client IDs for in oauth it's just a stronger uh way of authenticating right public private Keys instead of just a simple symmetric key uh so we're actually going to leverage uh service accounts and Grant that service account the ability to impersonate all of our users in our organization ah and just because I didn't want to have a uh an unsecure service account with impersonation abilities running on uh on Ripple it uh I did wrap this in Google sign-in just to make sure that uh nobody else is going to like just hit this app and you know actually log in and try to first I need all my test users um so it is guarded but we don't have the authorization button anymore I can just list files and the way this is this works is you know as an admin I previously authorized this app to act as any user so if I were to log in as another test user who's never even touched that before as soon as I sign in and hit list files it's going to work no permissions are needed because the admin has already made that decision from a code perspective it's actually pretty simple right we use our drop client and we just add a couple extra claims we say uh the Scopes that we want and we get give it a subject and that that jot the same draws that we use for identity for Google sign-in we can exchange that much in the same way that we exchange the authorization code in the previous example right so we just say like you're going to a Google identity the Google Account Services we say hey like on this app I want to act as this user doing the scope give me an Access token and if that Grant exists if the admin went through the proper steps you get back in Access token and then you can start using apis just as if the user went through the oauth flow themselves you're just short-circuiting that entire process [Applause] there are a couple different variations for how domain-wide delegation Works depending on how you're using service accounts in this particular case I'm using um a private key that I downloaded right so I can I can sign that I can create the drop locally sign it and exchange it entirely within the application if you're running on gcp if you're running a cloud run or Cloud functions a lot of times you don't have the private key right it's actually somewhat discouraged actually download the private Keys these days um and so you have an alternative where you can actually do a remotely signed uh job so we have an API that aren't actually just called sign jot appropriately named part of the iam apis um and so long as you have the service account token Creator rule you can call the API with the payload that you want signed it will sign it and then you go around and exchange that for an access token for that user your mileage for how easy that is in any particular language depends on the client libraries some of them make it really easy there are a handful of the the client libraries where that particular version of the flow is not very well implemented so you might have to do a little bit of a little bit of the work that hidden in the node.js version you might have to sort of break those steps apart and um you know handle the exchange yourself so like the we looked at like four different scenarios for this um and really like the the there's a whole bunch of scenarios that we didn't even talk about right like there's a lot of this is going to vary depending on if you're building a mobile application right like the flu is on Android are a little bit different than they are on iOS versus a web app if you're building a desktop app right if it's a command line versus like or something built with electron all of these things are going to have slightly different variations to how they're done right but they all fit Within These buckets um you know to some extent but the main the main point is like how difficult oauth is going to be and how much work you have to pay in attention to security is really dictated by your use case uh and really the thing is just to do is it's be lazy right like that that is my recommendation it's like really only do as much as you actually need for the problem you're trying to solve right and that's usually the where I see developers get tripped up is they uh very often will jump to the the most complicated way of doing oauth um when really what they need is is much much simpler and you know so you know depending on what you need to do like you know if you're just tinkering around do apps script apps script is super awesome for a quick hack um if you're building a commercial uh application you're going to sell it to lots of customers and you need to scale you're probably gonna do something with implicit or code flow right um I would not recommend domain-wide delegation for you know multiple customers it's just a lot of security risk um you know those are really only focused for internal cases but really most of the applications are going to be kind of in the middle and it just depends on do you need offline access or do you need uh if it's only for when the user is present but you know that's that's really the the main takeaway it's just you know do do the least amount of work recommended right like that that's it um so one last thing I want to talk about um we've got about two minutes left is uh sort of the elephant in the room with oauth and I don't know how many people have actually gone through this process before um but there is an improval process for oauth and your experience with that process can very wildly depending on a bunch of different factors so the good news is if you're just building something for your own or you're building something for yourself it's easy right there's no process there's no approval it's your data do with it what you want and nobody cares if you're building something for other users you're going to sell it to customers or consumer accounts or schools or whatever then it becomes a risk-based process right if you're just doing sign in and all you want to know is who the user is it's usually pretty easy two three days uh really they're only looking at your branding information do you have a reasonable terms of service privacy policy and so on and again usually turn around into a couple days if you're requesting data access then that's going to depend on how much data you're asking for right so if you want access to just a little bit of information in workspace you might get by with a self-assessment um running some automated security tools just to structure to check the things are okay um but if you're asking for like full access to everything in uh in drive and you have a huge customer base right well that process might start to involve a third-party security audit and the timelines can actually be on the order of several weeks to a month or two um the point of this isn't just scary and say like oh like this is this really crazy process that I have to navigate it's really not that bad and the process has improved a lot over the last couple years it's really just to make sure that you plan for it right and so like if there's like three three lessons from any of this it's like understand your use case and be lazy um security matters but you don't have to be an expert and just plan for the process right um most of the escalations I see like that come my way from partners and so on is are really just that nobody planned for the the approval process and so it's they're like hey we're gonna launch on this date and they just submitted their route two days before their launch and you know then they get a whole bunch of feedback that's going to take them four months to fix right and like that is not a situation anyone wants to be in um but if you you know sort of understand the requirements early you plan for the reviews you plan for doing the security analysis it's actually it's a pretty manageable process you know pretty much every developer ever worked through has successfully made it through right so like don't be scared just plan so that's all I have just a couple of things uh last resources I certainly encourage everyone to check out uh in the innovators Hive area we have um the entire workspace developer relations team we're happy to chat answer whatever questions or just learn about what you're doing a whole bunch of other sessions a lot of these have already happened but you can check them out online uh you could also sign up for our newsletter it's a Once once a month uh newsletter you can sign up for we just give you kind of what's new and noteworthy with any workspace apis and of course you can follow us on LinkedIn and Twitter and and so on and of course as always any feedback that you have on the session certainly uh happy to have that it would just help us make sure that we give the content that you need for future events and that's it that is all I have and I'm happy to answer questions or chat with people in the hive section um you know for the rest of the day or tomorrow so thank you very much [Applause]
2023-12-17 17:46
