I have used OAuth1+XOauth to connect to Gmail for a custom enterprise application. The application is being used by many customers. Now some of them are reporting that, it's not working correctly for few users in their organizations. I could see in the Gmail Page that Google has deprecated OAuth1 and asked to migrate to OAuth2. If that is the case, May i know, if Google still accepts OAuth1 tokens as i could see that its working for some of the customers?
Please let me know if i can provide more information, as this is a high demanding feature for our enterprise
Thank you
OAuth1 for consumer accounts was shut down last year but we gave a longer grace period for enterprise customers so they can migrate. That is why it is still working but expect it to shut down in the next few months. Is there a reason, you don't want to switch to OAuth2?
Related
As an ios/android app developer, my pain point is having clients sign up for the various 3rd party accounts needed for their app to work (e.g. google cloud, mapbox, firebase, etc.), however with 2-factor authentication (2fa) being a requirement on most accounts, it makes it difficult to get into these accounts easily as the developer (since 2fa requires a code being sent to the client which must be entered in a limited time period).
Has anyone found an easy solution for working with 3rd party accounts for their clients especially when 2fa is being used?
Well, at least Google Cloud and Firebase in this case have the option to add additional users under a given role. In this case you would likely want the client to be Owner of the project, and ask them to invite you as a developer, this way you can sign in with your own Google account (either gmail or your personal if you use google workspace), hence bypassing the need for 2FA.
In general, there are things that you don't really want access to as developer, such as billing information, so it makes sense to ask for limited access. Both Firebase and GCP have predefined roles for this, you can do some research on them to find out which makes the most sense for you and advice your client.
Read more about the roles here:
GCP: https://cloud.google.com/iam/docs/understanding-roles
Firebase: https://firebase.google.com/docs/projects/iam/roles
Side note:
If you are working as a freelancer, I would recommend to never create accounts for your clients, if you are working with specific service, ask your client to setup the account (this will primarily protect you, if the client backs out or the server costs for development build up if the project is taking long time to finish)
I have created an application to use the Office 365 Exchange Online (Microsoft.Exchange) API. I set successfully set up permissions as described here MS Integrating Applications on an existing development Azure Account. See APIs available on original account.
However, now I want to set up a similar app in a new Azure account so I can have a different visible domain for the permission sign up process. However, on this new account the Exchange Online API is not visible to select as a required permission.
This account only exists as a place to register the App so it doesn't itself have any users or need any licenses but do I have to have a license associated with that account just to be allowed to add a particular API to the required permissions? The documentation doesn't mention anything about this that I can see.
do I have to have a license associated with that account just to be
allowed to add a particular API to the required permissions?
Yes, you're right. You have to have a Office 365 Exchange Online license for your Tenant.
Why:
These APIs are exsiting in the AAD as service principal (Enterprise Applications). If you don't buy Exchange Online license, it won't occurs in the Enterprise Applications in your tenant. Once you buy the license, it will be automatically added to the Enterprise applications, meanwhile you can use its API via AAD.
This makes sense because if you don't have the license, you cannot use the product and you cannot use its API neither.
The documentation doesn't mention anything about this that I can see.
Yeah, the documentation maynot mention this and it should be noticed in the documentation. You can sign in the documenation webiste via a github account and give a feeback to the documenation Team:
Hope this helps!
We've been working with EWS Managed services for a while now, however we would like to transition over to using the RESTful API for Office 365.
Is it possible for an application to access all of our users data without their consent? We have an in-house application that we would like to get some O365/Sharepoint data to our users. Using SSO isn't really an option, as we don't want to keep asking our users to give consent (we assume they already give it). Specifically, we want access to calendars and mail.
Are these "service/application level" accounts available in O365 yet? I think I read a while ago that they are on the roadmap but I have not seen anything since.
Would it be best for us to continue using impersonation with EWS for now until it is ready? (For some reason, EWS is painfully slow when getting data, meanwhile our tests with O365 SSO are a great deal faster, but we do not want SSO).
Apologies if this does not meet the requirements for SA questions. Thanks.
EDIT. Daemon and Service Apps are now possible with Office365. Check out this link.
Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow)
App-level authentication is coming soon. Basically an organization administrator will have to consent to allow the application access to mailboxes in their organization, then you'll be able to authenticate as the app, rather than acting on individual users' behalf.
I'd say keep working on your prototype using the user consent model that's in place now, and keep an eye on our blog or my Twitter account (#JasonJohMSFT) for the announcement for app-level auth.
I'm looking for a solution where a customer will fill out a payment form (subscription base) and customer information form on my website. The payment will go to the QuickBooks Merchant Service and charge them every month automatically. We will also add the customer info to QuickBooks Online.
How can I do this without a sign in process since the customer will have no QuickBooks account or QuickBooks Merchant account. Also can I achieve this with no e-commerce storefront like BigCommerce.
I tried using the QuickBooks PHP DevKit "consolibyte/quickbooks-php" and everything works but you have to sign in first.
Thanks.
I was searching some more and will this help me out > "QuickBooks PHP DevKit for the Web Connector". I'll keep reading the docs.
How can I do this without a sign in process since the customer will have no QuickBooks account or QuickBooks Merchant account.
Use this library:
https://github.com/consolibyte/quickbooks-php
And follow the quick-start guide here:
for QuickBooks ONLINE: http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Intuit_Partner_Platform_Quick-Start
for QuickBooks for WINDOWS: http://www.consolibyte.com/docs/index.php/PHP_DevKit_for_QuickBooks_-_Quick-Start
Also can I achieve this with no e-commerce storefront like BigCommerce.
Yes.
everything works but you have to sign in first.
You have to sign in ONCE. Exactly ONCE. And then you NEVER NEED TO SIGN IN AGAIN. Of course you have to sign in at least once - how else would QuickBooks know that it's actually you wanting to exchange data with QuickBooks, and not some random hacker half-way across the world?
The sign-in is to authenticate and connect to QuickBooks THE VERY FIRST TIME ONLY. After THE FIRST SIGN IN, YOU NEVER HAVE TO SIGN IN AGAIN and can communicate without a sign-in.
This is standard OAuth, like every other OAuth platform on the planet. You sign in once to a authenticate yourself, and then you can do whatever you want from there on out.
We are using Google Apps services in our startup for email and docs. However for some other purposes such as svn and bug tracker we have our local machines on which we have installed the required apps. All of them have their own separate credential sets.
Ideally I'd like to have one authentication (i.e. that of Google Apps) and authenticate on svn & trac etc. using them. Considering Google Apps does not support OpenID, what should be a good solution? Can I setup a server which uses a particular protocol and still nicely wraps around Google Apps authentication?
There is a Google Federated Login API now, it provides OpenID services. Also, as this guy has shown, it's easy to use Google App Engine to create an OpenID provider of your own using Google IDs as the underlying credentials. HTH.
OAuth may help, up to a point -- Google Apps' gdata APIs do support it decently, see here. Of course all this requires and concerns programming, not just system administration: but then I know for sure your question IS about programming, since it's on Stack Overflow -- if you meant to ask strictly about sysadm issues, you would of course be using serverfault.com, right?-)