My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.
Related
Assume that there is an application, SPA, that uses Google OAuth2.0 to access the Google Drive API.
Reading the docs, the application flow seems familiar enough on the client-side specially with Google's JavaScript library for authentication. However, I have stumbled upon a roadblock during application registration phase.
When creating the credentials for our client application, I am redirected to fill out the form at the OAuth Consent Screen first. There, among other things it demands us to declare whether the application is in Testing or In Production phase, so it can decide whether the app will be available to everyone or to Test Users only.
Assume I create a project for our application and set it on testing at first and then change it to production once I am ready to publish (with a new set of credentials as well).
My question is this. What if development continues on the application for new features while one instance of the app is in production? During development and testing I would need to restrict the application to my Test Users alone. Since the OAuth consent screen is project specific, not credential specific, will I require multiple projects on the console for every environment in which the application is running?
As in,
Project MyAppTesting will permanently remain in testing mode and will denote our development/testing branch.
Project MyAppProduction is always in production and denotes my production branch.
Similarly for the mobile client:
A MyMobileAppDev project having credentials configured with the debug keystore hash
A MyMobileAppProd project having credentials configured with the production keystore hash.
(both sets of credentials share the same package name).
Is this the idiomatic way? I failed to find any documentation on the matter. Please advise.
What #JohnHanley stated is the best way and the best practice when deploying application/s in GCP.
You can create multiple projects and create different Oauth for each of the projects. Check out this link on service accounts.
In addition to that, there are also some pros and cons when it comes to billing.
Pros:
Users consider having multiple billing accounts with respective projects assigned for each account to be able to see their billing details separately. In this way you can monitor the billing for each of the respective projects for each account.
Cons:
Attaching all the projects to one billing account, however, the billing reports will show all of the sum of the cost for all the projects, but you can still use the filter menu to be able to see the charges for each project.
My question is how a 3rd party developer would login users through my Identity Platform? I looked at the documentation but found nothing.
Essentially I want to use Identity Platform as an OIDC Provider, but I don't know if that's supported.
Cloud Identity Platform is based on Firebase Auth product (literally because the documentation and the Javascript to add are still in Firebase perimeter!).
This product allows you to delegate the authentication to a third party, either Firebase auth if you use login/password authentication, or to connect Identity Provider (IdP).
There is several built in IdP like Google, LinkedIn, Facebook, Twitter,... and you can add custom Auth0 provider (SAML) and OAuth2 provider (OIDC).
The platform only allow you to perform an authentication and then redirect the user to YOUR app. Then, it's to YOUR app to ensure the correct authorisations and roles of the user.
All of this for saying to you:
Think about firebase Auth feature: originally, it has been designed to authenticate user that wants to connect to Mobile App, on Android. Today it's the same thing but, in addition, for your web app
It's designed for YOUR application with YOUR roles and authorisations. By the way, if your target is to allow your 3rd party developers to log into Google Cloud console thanks to this authentication mode, it's not possible.
But, stay tuned, awesome things are coming soon on this field
John is right, more details would help. But if I had to guess you are referring to the fact that Google Cloud Platform IAM does not handle Identity part only authorisation. You could, however use G Suite or Google Directory Sync (which can integrate with LDAP server or Active Directory.
You can refer to the link below which shows you how you can integrate with OIDC:
https://cloud.google.com/solutions/authenticating-corporate-users-in-a-hybrid-environment
Essentially, I'm wanting to create an Oauth Client as an App so I can get data from Dynamics for multiple customers. Does anyone know if this is possible to do in AppSource or do you know of another way?
I have a service that will be served in a cloud different than Azure so there really isn't anything for me to submit as an App and I really don't want every customer to have to setup their own App that gives my service the privileges/access it needs, but it's looking like I may have to.
It sounds like you'll want to register an app with Azure AD (the OAuth2.0 service/identity provider for work and school accounts), and create a multi-tenant app. Then you can configure this app in the Azure Portal to get permissions to the APIs the app wants tokens to call (in your case Dynamics or the Microsoft Graph).
Once this app is written, you can code up your app using one of the Azure AD Auth Libraries. Here's some sample code for a .NET web API. You can find more code samples on Github and search active directory. Moreover, the Azure Active Directory Developer Landing Page is a great place to look for more resources on doing all of this.
We have an existing Android and iOS application that consumes REST API from our servers. The API provides a token to the authenticated users after they log in using their credentials (username, password combo.) from the mobile applications.
Now, we're planning to create a Google Glass application for the same. In this case, we'd like to use the existing REST API along with Glass also. The Glass app will be built natively using the GDK.
My concern is, how would the users be able to input credentials? Because, users may have signed up for the service using non-google accounts?
Many thanks in advance.
At the moment, there is no supported way for apps made with GDK Early Access to authenticate the user or provide a way to connect the Glass account to your auth system. The Glass team has indicated such methods are coming, however - the Strava Cycling app, for example, does this, and it is expected that a similar feature will become widely available as the GDK matures.
Strava Cycling appears to get its credentials at the time you setup the app through MyGlass. When you turn it on it redirects you to a website to log into Strava's service before completing the install.
I just gave a talk on this exact topic at Wearables DevCon. The solution I proposed is purely done through GDK. All the user has to do is sign into their Google Account on a phone/tablet/computer and enter a code that is shown on Glass.
Check out the slides here:
https://docs.google.com/presentation/d/1NepYwlKdEvLV0QH9ix2I8l-JY1kHjBR9AXKBNpgTI6g/edit
And the code here:
https://github.com/victorkp/GlassWebNotes
The latest Glass release (XE16) publishes the remote authentication API for apps distributed through MyGlass:
https://developers.google.com/glass/develop/gdk/authentication
We have an app in the Google Apps Marketplace (the new one, i.e. using OAuth2) which needs to get a list of users in the domain.
We're currently using the Provisioning API for this (which we know is deprecated, but there seems to be no better option). Lately however, we're starting to get "You are not authorized to access this API" 403's, for some domains.
Does anyone know why we're suddendly getting 403's, a bug perhaps? There seem to be some other bugs as well, for example the scope https://apps-apis.google.com/a/feeds/user/#readonly doesn't work, but https://apps-apis.google.com/a/feeds/user/ does.
Does anyone know when it will be possible to start using the new Admin SDK Directory API to get a list of users? This isn't possible now because even when an administrator installs the app, it would only work if they go to their domain security settings and manually check "Enable API Access", see the related question here: How can I access user info on a domain without the domain administrator enabling API access?
You can start using Admin SDK Directory API. The question you linked to was regarding the case where an admin explicitly disables API access. When they install and an app, we re-enable that setting and let them know.
Not sure about the 403s but that is an older API that is replaced by the Admin SDK.