0

How can I use a Google Workspaces (gsuite) user's application specific password to sign into Google's OIDC (OpenId Connect) auth endpoint and request an OIDC ID Token for that user?

Background:

Google turned off support for programmatic password-based authentication to gsuite and Google Workspace saying:

“Blocking sign-ins from less secure apps helps keep accounts safe. For these reasons, Google is limiting password-based programmatic sign-ins to Google Accounts.” Google: Control access to less secure apps

As an alternative to LSA (Less Secure Apps) Google suggests that apps can use "application specific passwords" to programmatically authenticate to Google.

An app password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. To help keep your account secure, use 'Sign in with Google' to connect apps to your Google Account. If the app that you’re using doesn’t offer this option, you can either: Use app passwords to connect to your Google Account ... Gmail: Sign in using app passwords.

Google recommends using an App Password as one solution for applications that require programatic sign ins to Google accounts:

Can’t use an app with my Google Account: Use an App Password Google: Less secure apps & your Google Account

This clearly indicates that Google intends for applications to programmatically sign into Google Accounts using app passwords but forbids programatic access for regular passwords. I can find no documentation on how to do this.

My question is: how can I use an app password of a user to sign into Google's OIDC (OIDC Connect) auth endpoint and request an OIDC ID Token for that user?

I can find examples of this being done for Google Workspace SMTP to access email. For instance Google only allows nodemailer to programmatically access gmail via the SMTP protocol using an app password. This however does not help me because SMTP being a email transfer protocol can not issue OIDC ID Tokens.

Out of scope answers:

  1. This is not a question asking how to create GCP service accounts and use domain wide delegation to enable them to impersonate a Google Workspaces user and thereby request an OIDC ID Token for that user.
  2. It is not a question asking how to create an OIDC confidential client and then given that OIDC confident client access to your Google account to request an ID Token.

I am not looking for these answers.

Ethan Heilman
  • 16,347
  • 11
  • 61
  • 88
  • An app password probably isn't the solution you are looking for. App passwords are not used with oauth flows. You should get the user to sign in with their Google account and securely store the refresh token so that you can create access tokens when needed. The process is described [here](https://developers.google.com/identity/protocols/oauth2) – Paulw11 Jun 10 '22 at 21:43
  • App passwords can be used with oauth flows as oauth is how apps interact with google APIs in a trusted fashion. What would an app do with an App Password if not to request an oauth token? – Ethan Heilman Jun 10 '22 at 22:12
  • App passwords are for non-oauth protocols, such as IMAP, that require a username and password. That is why you can find examples on using it with GMail. If you follow the correct google OAuth Google authentication process; Asking the user for access to specified scopes then you receive the token you need. There is no need to use a password. This is more secure because the token is linked to your applications client id and secret. An application specific password isn't. The document I linked to explains how apps interact with Google APIs in a trusted fashion – Paulw11 Jun 10 '22 at 23:00
  • Also, using the correct sign in flow is more user friendly; The user access your app, uses the "sign in with Google" button or whatever, is prompted to authenticate and prompted to grant the scopes your app requests. If they use an app specific password, they need to find the right section in their Google account, create a password, copy it and then come back to your app to paste it in – Paulw11 Jun 10 '22 at 23:06
  • App passwords are used for oauth by google itself! For instance google uses android.clients.google.com/auth to issue IDToken from app passwords. However they don't document that API and I'm concerned about depending on undocumented apis. The "sign in with Google" flow is not more user friendly if you are using this for managing purely automated gsuite accounts in situations that can't support domain delegation. App passwords make sense in a programmatic setting. – Ethan Heilman Jun 10 '22 at 23:09
  • You want a client_credentials grant type, which is not supported. See - https://stackoverflow.com/questions/40102110/can-i-use-grant-type-client-credentials-for-google-api . If you want to access multiple Google workspace accounts in a single domain, a service account with domain delegation is the correct approach. If you want to access individual workspace accounts across multiple domains or "consumer" google accounts then you need the account owner to authorise your app. – Paulw11 Jun 10 '22 at 23:34
  • And I still don't see how an app password helps; You need the user to generate and supply the password, which is a relatively complicated process. Your app can't do this automatically. You can provide an oauth process by which the user connects their account with your app and it is much easier. – Paulw11 Jun 10 '22 at 23:35
  • Let's say you have five gsuite accounts that you want to request IDToken for a few hundred times a day. Once you set the app password up once you are golden. Believe me I've used OAuth2 confidential clients, I've used service accounts, I'm used the web browser OIDC auth code flow. I've set up refresh token based automated systems. I generated an IDToken in programmatic fashion using a private_key_jwt GCP service account. It's not that I am unaware of these things. – Ethan Heilman Jun 10 '22 at 23:44
  • Once those 5 gsuite accounts have been through the OAuth flow and you have the refresh token you are golden. You can request access tokens as you need them. The refresh token plays the same role as the app specific password, but it is more secure and simpler to generate and managed for the user. – Paulw11 Jun 10 '22 at 23:46
  • 1
    Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/245508/discussion-between-paulw11-and-ethan-heilman). – Paulw11 Jun 10 '22 at 23:46

0 Answers0