I am trying to achieve the following:
an authenticated user uploads a video on my web application
my web app stores the video, logs it in our database etc. then connects to a Google account and makes a request to upload the video to a Youtube channel within that google account
I've created the Google account, enabled the youtube API, configured OAuth 2.0 access etc, but I'm not sure that any of the documented workflows meet my requirements. (For example I don't want any user interaction as part of the authentication process).
It looks like a Service Account ( https://developers.google.com/accounts/docs/OAuth2ServiceAccount ) is what I need, however these accounts dont appear to support all Google APIs, or at least not youtube.
Does anyone have any advice / has anyone implemented something similar?
When you say ... "For example I don't want any user interaction as part of the authentication process", how will that work.
The user might not be logged in to Google, or might be logged in to multiple accounts so will have to choose which account to use for your app. So the potential for user interaction is unavoidable.
Once the user has authorised your app, logged on to your app (ie. accessed it and you've stored his user id in the session), then future accesses will be devoid of user interaction; at least until he logs off.
The difference between service accounts and user accounts is not the auth flow. The difference is that with a user account, the API access is by the user via your app (so the video will be "owned" by the user. With a service account, your app IS the user (so the video will be owned by you).
I'm not saying that Service Account is wrong for you, just that your reason for going that way is not quite right.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I'm currently trying to build an 'account switching' feature for my iOS App that uses Google Sign-In (with YouTube scopes to get YouTube channel data) & Firebase Authentication.
At the moment, if users want to switch accounts, they have to log out and log back in with another Google account, which is not great from a UX perspective.
My end goal is to allow users to log in with several channels and then choose the YouTube channel they want to see data for, from inside the app, without logging out and back in.
Is there a way to maintain several OAuth sessions alive to let user easily switch between accounts?
I have thought of storing the user's access token locally in a dictionary that would map channel ids with the relevant token but I'm not sure if that will be enough to maintain the state properly or if it will lead to a bunch of bugs.
Any ideas or suggestions are more than welcome.
Thanks.
With Firebase Authentication, there can only be one signed in user at a time. The SDK can't manage multiple signins at once. The prior user needs to be signed out at the time a new signin is processed.
Our app requires Google OAuth2. When a user, with an existing Google account, authenticates with Google then we use a callback to return users to our App. This is what we want.
The issue is, for those users who do not have a Google account we ask them to create a Google account (gmail address) or connect their existing email address to Google. A user who has to follow either of these flows ends up on the "Thanks for creating a Google account page" and not back at our App.
This is supposed to work as you are expecting. There is a continue button on that page and that should bring the user back.
If that is not working, can you tell us more (about OS, client id, urls and the exact steps) or give us a link to test/reproduce? Is this on the web or on mobile app?
I'm looking into creating a single-sign-on portal built in ASP.NET MVC. This single sign on portal should give users the option to sign in with their individual account (which should be verified against AD) or their Facebook/Twitter account. What I'm still in the dark about is if the application/authentication flow I came up with is actually feasible. This is how it should work:
User logs into the SSOP with his AD account (using a custom form where he enters these credentials). The SSOP verifies these credentials against AD and logs the user into the SSOP accordingly. The SSOP then offers the user to start any of the applications he has access to (based on his group memberships in AD). These applications are built by various third parties and are not all .NET based. Clicking one of these applications in the SSOP should log the user into this application using the credentials authenticated against AD that were used to enter the SSOP. I currently do not know how this should be done, e.g. by using claims or some sort of auth token? Obviously the receiving application should support whatever option we choose, which means we're looking for a best practice of some sorts.
The social login part of the SSOP should work somewhere along the following lines: The user logs in using his social account. The first time he does, he also has to enter his AD account credentials so we can link his social account to a specific AD account. Every subsequent time the user logs in with his social account the SSOP should log in the linked AD user. That way the SSOP always uses a valid AD account to authenticate to the applications it offers the user. This also makes it easier to administrate the user base since these are all stored in AD. The social login links and any other SSOP specific data is stored in a custom data store (MS SQL db).
I've been looking into the ThinkTecture IdentityServer, but have yet to figure out how it can be used in this scenario or if this scenario is even feasible.
So, the question basically is: is this authentication flow even possible or remotely best practice? If so, where to begin? And if not, what is?
We are using google oauth2 permitting users to use their existing google accounts to log in to our system.
After being authenticated what is the proper way to manage active user session in our app for ex.
Let's suppose the user has logged in to our system with google account A. Then user logs out/changes google account to account B but not within our app but rather from its gmail. Should we also log him out him from our app???
(which seems to me bizarre and impossible as soon as there should be google API to check that the given user at the given time is logged in to google services).
The only way which seems to me reasonable is to invalidate user session after given timeout and only then we could make user re-pass oauth2 authorization flow.
Thanks in advance for your help.
The access_token or id_token your acquire from the Google OAuth2 Login flow is not coupled with the login sessions in the various Google apps (gmail, plus, ....).
There's no way for your app to know that the the user logged out of his gmail. Your app shouldn't care.
If your web app makes it clear to the user what account has been used to login initially (by displaying a username/picture or other info retrieved from the Google User Info call you should be ok.
Most users will not try to link your web application session with a gmail session for example.