I am trying to configure Gmail API in a way so I can pull the inbox messages as well as respond against them. Basically, I am implementing a CRM and this one of the modules of that CRM. I got an email from Gmail verification support telling me that this needs to undergo a security assessment if your application can send Google suer data from a restricted scope to remote servers. For third-party security assessment, they mentioned that it may cost from $8,000 to $75,000. Is there some other way to tackle this? This is too much!
Related
can GMAIL API be used for sending out account verification when registering to a site?
I plan to use it for email registration , verification, forgot password for transactional use
Yes it can but you may not want to unless you are using Google workspace.
To send an email using a standard google gmail account you will need to use Oauth2 and authorize the user who owns this account. Using Gmail scopes with an Oauth2 will require your application go go though a security audit. This audit is expensive and time consuming. Its up to you to decide if this is worth it or not.
You could go though the SMTP server and use something called an Apps password to authorize it. This solution would work but, google is shutting down unsave apps now and i fear that apps password will me next. If it is your only option then would be to use Xoauth2 with smtp. Which again may require that you verify the app.
If you do have a google workspace account then you could set up domain wide delegation to a service account allowing it to impersonate a user on your workspace domain. This solution would work without any issues. It would be optimal in my opinion.
I have built an API to my web application so that customers can access certain functionality without going through the dashboard. I have secured it by providing an API key to each customer that identifies them and restricts the IP address from which they can connect.
I have now had a request from a customer to allow them to access this API from their Salesforce platform. I don't know much about Salesforce, and when I asked them to let me know their IP address so I could create their API key, all they could give me was the list of reserved IP addresses published by Salesforce. This IP space is huge (millions), covering all of Salesforce, meaning that if someone gained access to the API key they'd be able to use it from any Salesforce account.
I have read some things about Salesforce having an OAuth service and having some kind of Application Connect service, but it mostly seems to be designed around allowing 3rd parties to connect to Salesforce - I'm getting a bit bogged down trying to determine if this is any use in my scenario (which requires authentication in the other direction).
I'd be grateful for any insight into whether there's something more specific I can do identify a particular Salesforce customer beyond simply putting dozens of CIDR blocks in my API key. I could ask my customer to identify themselves in the referer header when they call my API, for example, but of course that's trivial to spoof.
Thanks.
IPs can be spoofed too
Salesforce has a concept of "protected custom settings". You could make a "managed package" (Salesforce plugin, but you don't need to distribute it on their appexchange, Google Play/App Store equivalent), install it for the client and then enter the API key to the setting in a way that even client's sysadmins can't read it.
It'd be bit of work to set it up but might pay off if you think you'll get more customers on the platform.
How about a crude but effective iframe? or a link to your page they'd embed somewhere in their app?
Do you have just api keys? If you'd expose OAuth2 endpoint SF users could login to your app and then SF code could use access_token they got back instead of api keys. Or maybe you can protect access with certificate? Calling app would have to sign requests with a certificate. Client could upload it to their SF, you'd upload to your app...
You could demand the API calls to include the user's SF "session id" and you could use that to run some queries against source SF org. Org Id, user's login history etc things that are impossible to tweak even by sysadmins...
First of all, I apologize in advance for my naïveté on the topic.
I am trying to create a few microservices that are exposed using an API gateway. A few of these services will need credentials from Google account to access Google Calendar/Gmail etc.. is there any way for a user to only have to login once so that the credentials are all shared between the services? Or should only one service be facing the Google services with credentials?
It seems possible, you can ask a user to authenticate and authorize all permissions your application will need, all at once. But think about the user, when an application requires to access gmail, hangouts, photos, camera, etc. at once, the user normally disbelieve the application. So, the recommended approach is asking for the specific permission when the application requires it so that the user can realize each action you app do.
There exist many different ways to address your question depending on details, however the following link can help you to know where to start:
This link (Google Sign-in) has a wide context on all the Identity mechanisms to look for the most appropriate for you.
This another one explain all possible Identity mechanisms for specific use cases.
This authentication example for Google Calendar is useful, but this post explain how microservices authentication and authorization was solved.
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
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.