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...
Related
A little baffled by the Adobe Analytics Oauth integration. I have done many OAuth implementations with other providers in the past, and used the older versions of the Adobe Analytics API.
My company provides services to clients who use Adobe Analytics, we do not have an account of our own. In the past we just needed to be provided the user and shared secret and we were good to go. Now it seems that we need to have an integration created by an admin in the client company, and have them send us the client_id and client_secret securely. This does not grant us access instead it is the first step in requesting access. Once we have this information we can do an OAuth request, using a valid adobe id with proper access and then we will receive the token we need to request data.
With other OAuth integrations I have seen, the client_id and client_secret are not tied specifically to a given account, but rather to the application. In this case it seems we will need to have a new set of client_id and client_secret created for one application, for each account we need access to.
To clarify the use case.
I work for Define Media Group an Audience Development Consulting Firm
specializing in SEO.
Many of our clients are news organizations, for our purposes here,
lets say our client is the fictitious Newscor. Newscor uses Adobe
Analytics and has come to us to provide insight into how they can
improve their SEO performance.
As part of our analysis of Newscor we will need to look at the
Analytics data for all of the requests to their site from Googlebot.
We will use the Adobe Analytics Reporting API to retrieve this data
and perform our analysis.
In the case of a second fictitious company, Newscom, who instead used
Google Analytics, I built an application, I logged in with a Define
Media Group account to the Google API Console and generated a service
account for my application. This provided the client id and secret
needed for completing the OAuth process. Now I just need to have our
SEO contact at Newscom, access our page and complete the OAuth process
with his credentials and I will be able to complete the analysis on
his behalf. Very straight forward.
In the case of Newscor, I am stuck. I have asked my SEO contact at
Newscor to have a service account created and provide the client id
and secret. Instead he provided me his username and password. I told
him that was not what I needed and would not work, confused he has a
user account created for me, and again I have to inform him that this
will be useful, but is not what I need. I send over a link to the
Adobe documentation on how to create an integration account, before
following those directions I am sent a few other random strings of
characters in hopes that one of them will give me the data I need.
Finally, the integration account is created and the client id and
secret are pasted into an email and sent to me over SMTP, plain text
you know. Because users understand security and the complex side of
OAuth, so it is totally reasonable to have them sending client
secrets.
Yes the old credentials were also broken, I thought perhaps, a new API
based on a community standard would resolve that, instead it seems to
have made it worse. Instead of sending me one set of credentials he
has to send me two sets, the client id and secret and a username and
password for an adobeid. The idea behind OAuth as I understand it was
to entirely eliminate this and require that they send me no secrets,
but rather visit a secure page and grant me authorization through the
OAuth process, a familiar login and a few clicks, with secure exchange
of information. The OAuth client_id were between me and Adobe where I
was able to download that information through Adobe's secure website.
That same client_id and secret will be used when Newscom converts to
Adobe Analytics, or another client comes to us with an Adobe Analytics
account.
Avoiding third parties needing to exchange secrets is a primary reason that Oauth exists. Requiring exactly that exchange makes this less secure than a username and password alone.
Posting here, because that is where Adobe directs people to ask questions.
Is this really the way that the new Adobe API works for OAuth or is there something I am missing?
Does it seem reasonable to expect each client to generate a new application integration?
Does it seem reasonable to expect each client to generate a new
application integration?
Well this is just opinion, but yes, I do think it is reasonable to expect each client (Company) to generate their own application Integration.
FYI, the previous user/shared secret you are used to is also tied to an individual adobe analytics account, and is also something the client would have had to setup and provide.
In this case it seems we will need to have a new set of client_id and
client_secret created for one application, for each account we need
access to.
I'm not sure I understand what you mean by this. What exactly are you looking to do with your app? For example, if you are using the Adobe Analytics Reports API, you have the Integration credentials + Your own credentials and you can make Report requests with just that. You do not need credentials for any other user account.
Or, if you have a web interface, you have the option to have the users authenticate with their own credentials.
Overall, the Integration is the middle-man between the Adobe APIs and the user(s) requesting them. The users use their own credentials that they should already have.
Here is an example of it in action (press the login button at the top of the page): https://adobedocs.github.io/analytics-2.0-apis/
Under the hood, there is only one Integration setup, and any individual authenticates with their own Adobe ID login credentials, and what they can actually do within the app depends on what kind of permissions their Adobe ID has for that company.
Perhaps it would be easier to explain the flow if you provide example of what your app actually does?
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
I am developing software that will be used on small system at clients. The software is fetching Google calendar events from whatever Google account the client adds to it. The thing is that Googles API requires an secret key to work. As it is now, the system is working but the key is directly in the code, which means that the end user will be able to see it.
Firstly, is this a problem? I guess that because the key is "secret", there will be bad if a client can see it. Second, if this is bad, how should I do to avoid this? Is it even possible?
I should not be a problem since the key alone is not enough to generate an access token. You also need a refresh token or authorization code for that.
One risk is that, using the key, one of your clients (Alice) builds an OAuth authorization URL and tricks another of your client (Bob) into authorizing Alice's custom application to get calendar data. That problem only occurs if you're using the "installed application" workflow with the "urn:ietf:wg:oauth:2.0:oob" redirect URI.
If you want to avoid this problem, you can decide to host a web service that will handle the authorization for the embedded system. This web service will hold the client secret, and will receive call from your systems to either request authorization from a customer or refresh a token. Of course now you need to secure this web service, but you can probably do that with a customer-specific set of credentials. That way the only thing on the customer's premises are his specific credentials to access the webservice, nothing else.
I am in need of advice on how best to tackle the following scenario and best practices to implement it.
Our company wants to overhaul its old IT systems and create new website app(s) and possibly mobile apps down the line for its employees and contractors to interact with.
So i was thinking about creating an api that both the website apps and mobile apps could be created from...
https://api.company.com/v1
The advice i need is in relation to security/authorization of the api. My thoughts at present in how to implement this would be that the employees/contractors would interact with the api through the companys website app(s)/mobile apps which would then communicate with the api and set the appropriate access permissions
WebsiteApp.company.com ->>> api.company.com/v1
mobileapp ->>> api.company.com/v1
First thoughts is just setting up a username and password for each user on the api side and let both the websiteapps and mobile apps use this. The problem however is that the contractors and possible some employees cannot be fully trusted and could pass on username and passwords to third parties without the company's permission. So my question is really what other security/authorization/authentication strategies should i be looking at to overcome this situation. In a perfect world each user would have to authorize each device/mobileapp/websiteapp he/she wants to access the api from...
Is OAuth 2.0 capable of this?, not sure if its capable of specific user/device/website scenario though ?
Technologies thinking of using are:-
API
Node.js with (Express js? or Restify?) , MongoDb
Consumer Apps
Website Apps (Angular Js, Backbone etc..)
Mobile Apps (PhoneGap, Jquery Mobile etc..)
Many Thanks
Jonathan
It seems that your main concern is that you can't trust the people you are giving access to, and if this is the case, you probably shouldn't be trying to give them access in the first place. If these apps are to be used for any confidential information or intellectual property that you are worried about someone else seeing if the contractor/employee gives away their password, then you have to consider the contractor/employee just taking the information and giving it away.
In this situation your username/password should suffice for authentication, however you should also consider very tight permissions on who can access what. If you are worried about information getting out, everything should be shown on a need-to-know basis. If a contractor doesn't need a specific piece of information, make sure it isn't provided to his account.
You could also consider tracking the locations (IPs) that an account is being accessed from. Perhaps when an account is accessed from a new location have the employee/contractor complete some task to validate the account; which could be anything from entering a validation code (similar to a two-factor authentication), to calling a help-line and having the location authorized.
This might be a bit late, but as i am going through the same process (What is the correct flow when using oAuth with the Resource Owners Passwords Credentials Grant)
We have not figured out the core implementation what you want to do sounds similar to what we are trying to do for our service.
From my understanding it depends on the apps and if they are trusted or not and what you plan to do with your API moving forwards. If the apps are trusted you could potentially use HTTP-Basic over SSL which is a viable solution.
For us, we are going to create a suite of trusted official apps (Web, Mobile etc) via the API and then open it up, so we are deciding to go through the pain of oAuth2 where for our apps we will use the Resource Owners Passwords Credentials Grant type where you swap a users user name and password for a token which is what the client will use to interact with your API with the trust implicitly defined.
When we open up the API for 3rd party consumption this model wont work and we will go through the processes that all the major sites do and get explicit permission from the user on what the 3rd party apps can do with their data.
We are starting to move our self-hosted internal services to the cloud. We've migrated some services to Google apps, but we have several application we developed ourselves that we would like to move to Heroku.
When we hosted them ourselves, authentication wasn't a problem, since being on network (physically or through VPN) was proof enough. Now that we're moving them to the big bad internet, we need some sort of login. Since all of us have google accounts, it makes sense to use them for that.
We've played with the Google OpenID option, however, this doesn't give you any information beyond the name and e-mail address, which we would then have to look up in the provisioning API, to check if that e-mail address belongs to a user we know of. That seems the wrong way to do it. Also, I'm not 100% sure that you cannot add any email address to any Google account.
I've read everything about the Google Auth APIs, but that seems to be about giving access to Google services, not our own.
So, is there a way to do Authorization (not just SSO/Authentication) with our Google Apps accounts?
If you're trying to use Google Apps as an Identity Provider, then yes, OpenID or the newer OpenID Connect support (see http://oauthssodemo.appspot.com) is the way to go.
In either case, there are other precautions you can take to make sure the email address really belongs to the user. For example, when using OpenID with Google Apps Google generally only asserts verified email addresses, and you can simply whitelist Google as a provider. If you're using the apps' version of OpenID (modified discovery protocol) then you can restrict OpenID requests to a particular domain (only make requests to that domain, an check on the response that the ID matches what was requested.)
In the case of OpenID connect, it's explicitly stated in the response whether or not it is a verified address.