I strongly agree with this. I have a large-ish user base on the built-in user database, some of whom are contractors without corporate accounts. Having the internal DB as a fallback would be ideal.

Without this, I can't really use this plugin, which is too bad, because having to maintain separate user DBs and credentials is tedious from a user and admin perspective.

This is critical to us as well. We have automation users, generic accounts for groups that only need read-only access to certain information, etc. We also have a situation where we have users in two different Google Apps domains, and both need access.

OK, so in this case, it sounds like you want Google Apps to be your primary source of truth but then have the built-in database available for users who are not in Google Apps, right?

So perhaps the right way to do this is to have add an option to the Google Oauth Security Realm which allows you to "Also authenticate users using the Jenkins User database". In this case, the login screen would show a username password login with a "Login with Google" button below it.

This is not how the "on the side" feature works in the old OpenID plugin. In that case, the user must explicitly configure their account to allow access using OpenID. But that doesn't seem like what you want in the use-case you are describing. You want someone known as "user@mygoogledomain.com" to be able to authenticate as that identity on Jenkins using their Google session without having to take special steps prior. And I imagine you want their Jenkins account to automatically be created if it does not exist. Finally, I think you want them to lose access to Jenkins if you disable their account in your Google Apps domain.

So this is not exactly like the "On the side" feature.

And what is especially important is that Google Apps users lose access to Jenkins once you decommission them in Google Apps.

The more I think about it, this is going to require a bit of work and especially thought to make sure we don't accidentally prevent logins somehow or (even worse) open up some kind of security hole.

Given the risks, the work to get this right and the relatively low votes on this issue, I think its safe to say we have no plans in the foreseeable future to add this feature. This may change if someone steps up to do the work or the demand increases.

I will say that if someone actually volunteers to add this change, I think it may be possible by creating another plugin which somehow wraps this one. This would be much lower risk than adding the feature to this plugin. If someone wants this enough to do the investigation to tell me what they need, I can make changes to support that.

It seems coherent to me what is exposed in the issue. Reopening to give a vote.