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?
Related
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...
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'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.
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.
I am exploring the possibilities of a banking mobile HTML5 application. It will be contacting with the main server via RESTful API. Very often I hear that people are using OAuth in their mobile apps to access APIs. For example, SpringSource's html5expense demo app.
So I don't fully understand why bother? Couldn't the user just login in a standard way, receive a cookie with session id (or in case of Play framework, session data), that will be used to identify user when the app makes requests to REST?
Oauth is usually a lot more secure than most BASIC AUTH, or "logging in in a standard way" approaches (and OAuth is becoming more and more of a standard).
When you login, through most "standard" ways, the user enters his username & password, into the application, and username/password are then often either stored locally, or transferred to the application, to then potentially be relayed to a "main server" that for example provides the API. So the user will have to enter his very secret login information (e.g. for banking?), into a client, app or system he doesn't know or trust...
With OAuth, the user is directed to a login page of the owner of that API .. e.g. his bank for example, where he logs into the secure login page that he knows and is asked for his consent that the application "xyz" would like to access his data.... The application that has requested that access, is then given a token with which it can access the API without needing to know the username and password. That way the username/password is only entered once, at a location the user trusts.
Furthermore, the user could later log into and admit page .. (the bank app? or and admin frontend), and delete the given access right to the API, and so stop an application accessing his information, without having to change his password.
Beyond the effect of being actually safe, using something like OAuth, for a banking app also makes sense as it will give people more confidence if modern security techniques are applied. It makes it also feel safer.
If you are not going to publish your API to third party developers; there really is no reason to bother with OAuth.
The biggest reason OAuth exists is to enable integrations with your API without your users having to give out their username and password to a third party. Other reasons is that it makes it possible to put a time frame on third party access to resources, or to scope access.