3 ms·

I wonder though how many open source apps will go through the mandatory security audit process (15-75K annually) since IMAP via OAuth is a restricted API scope

I wonder though how many open source apps will go through the mandatory security audit process (15-75K annually) since IMAP via OAuth is a restricted API scope [1]. [1] https://support.google.com/cloud/answer/9110914?hl=en https://support.google.com/cloud/answer/9110914?hl=en

geofft 7y ago
Ugh, I forgot about that. That said - from "What app types are not applicable for verification?" there are the following exceptions: > Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in. > Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. > Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway. So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions. If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file. So then there's just the question of actually making OAuth support exist in whatever apps employees want to use. EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch): > Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).

geofft 7y ago

Ugh, I forgot about that. That said - from "What app types are not applicable for verification?" there are the following exceptions: > Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in. > Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. > Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway. So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions. If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file. So then there's just the question of actually making OAuth support exist in whatever apps employees want to use. EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch): > Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).