I know this isn't exactly a how-to question, but Linked-In Support directed me to StackOverflow when I asked them this question, and I cannot find the answer anywhere after googling/searching the forums:
Per the LinkedIn APIs Terms of Use (https://developer.linkedin.com/documents/linkedin-apis-terms-use), section E.1, second bullet point:
Don’t try to exceed or circumvent your limitations on calls and use.
This includes creating multiple Applications for identical, or largely
similar, usage (e.g., having one Application per customer). If we
believe that you have exceeded or circumvented our limitations, or if
you have tried to, we may temporarily suspend or permanently block
your access to the APIs, disable your developer account, or both.
It sounds like I'm not allowed to create multiple instances of an application. However, the nature of my software is that each of my clients gets a subdomain and runs an instance of my app on a server particular to that client. Each client thus needs their own OAuth redirect_uri, and the only solution that I can think of is to create an application for each of my clients (which are organizations and not individual users).
Does this practice violate the TOS, and if so, what's a viable alternative?
If this practice is allowed, what is the maximum number of applications (and API keys) I can create?
Thanks in advance.
Register a single client/app but add multiple RedirectURI's for that instance, one for each customer/domain. This is allowed per LinkedIn documentation by adding multiple URLs in the OAuth 2.0 Redirect URLs text area, separated by a comma:
OAuth 2.0 Redirect URLs: Comma separated list of absolute URLs allowed
for OAuth 2.0 redirections.
Related
I have a microservice architecture, where one Single Page Application accesses three different APIs:
I am securing those APIs via the Microsoft Identity Platform and therefore I also need service principals.
My first approach matches with all the examples I found on blogs or in the MS docs.
In this case I have one app registration for the client app and three additional ones for the APIs:
This has the following impact:
Each API has its own audience.
I get four service principals for each application.
I get three different places where I have to administrate the user assignments to roles. (for example: User A can read assets from API A etc...)
This works, but comes also with some problems:
The other admins that are managing which user is allowed to do what are confused about three different places they have to assign roles. It would be nicer to have one central place.
The roles of the users are not placed in the ID tokens, because only roles of the client application would go there... but I do not want to assign permissions in the client app again.
If API A wants to call API B or C, I need two access tokens for other APIs.
This lead me to a second idea:
Here I have one registration for all 3 APIs. This already solves problem 1 and problem 2. But it also gives me a strange feeling, because I never found other people doing so.
Also my ID tokens are not telling me the roles, so to fix this, I could even go another step further to a single app registration for everything:
Now one registration exposes an API and consumes this API also. Something what is possible and seems to solve my problems. I even get all roles for the users in my ID tokens AND in my access tokens now.
However, this is contradictive to all other examples I found.
Which disadvantages does the last solution have?
Which of the three approaches should I chose?
Which disadvantages does the last solution have?
One thing that comes to my mind is that you want API A to be able to edit data in e.g. MS Graph API, so you give it the app permission to Read/Write Directory data.
Now with the shared app registration this permission has also been given to API B and API C.
So the principle of least privilege may be violated in the second and third options.
But it does make it easier to manage those APIs as you noticed.
The third option does open up the door for the user to acquire access tokens to any APIs that you might want to call on behalf of the current user from your APIs.
So if you wanted to API A to edit a user through MS Graph API on behalf of the user, you'd have to require the read/write users delegated permission (scope) for your app.
This would allow the user to acquire this token from your front-end as well, even though that is not intended.
Now they would not be able to do anything they wouldn't otherwise be able to do since the token's permissions are limited based on the user's permissions, so this might not be a significant disadvantage.
Which of the three approaches should I chose?
As with many things, it depends :)
If you want absolute least privilege for your services, option 1.
If you want easier management, I'd go with option 3 instead of 2.
There was that one thing I mentioned above about option 3 but that does not allow privilege escalation.
I'm trying to understand OAuth best practice implementation strategies for systems requiring access to protected resources backed by different authorization servers. The default answer is to use the access tokens provided by each authorization service and write the logic to store them on an as-needed basis, but the use case of systems requiring multiple, federated protected resources seems common enough that there might be a protocol/framework-level solution. If so, I haven't been able to find it.
Here's a hypothetical example to clarify:
I'm a user with an account on Dropbox, Google Drive, and Boxx. I'd like to make a backend API to report the total number of files I own across all three systems, i.e., Result = FileCount(Dropbox) + FileCount(Drive) + FileCount(Boxx). How to I organize the system in such a way that I can easily manage authorizations? A few cases:
Single-account: If I only have, say, a Drive account, the setup is easy. There's one protected resource (my folders), one authorization server (Google), and so I only have one token to think about. By changing the authorization endpoints and redefining the FileCount function, I can make this app work for any storage client I care about (Dropbox, Google, Boxx).
Multi-account: If I want to aggregate data from each protected resource, I now need three separate authorizations, because each protected resource is managed by a separate authorization server. AFAIK, I can't "link" these clients to use a single authorization server. As a result, if I have N protected resources backed by N authorization servers, I'll have N access tokens to manage for a given request/session. Assuming this is true, what provisions do software frameworks provide to handle this (any example in any language is fine)? It just seems too common of a problem not to be abstracted.
The closest related question I can find is probably this one. The accepted answer seems completely reasonable: one application should not be able to masquerade as another without explicit consent. What I'm looking for is (I think) slightly different: some standard methodology/framework/approach to managing multiple simultaneous access tokens per session. I've also wondered about the possibility of an independent authorization server that can proxy the others as needed and manage the token bookkeeping (still requiring user consent for each), but I think this amounts to the same thing.
Thanks in advance.
Apologies for the oddly worded title, however I could not come up with a better one.
My application should be able to perform a limited set of actions on an Enterprise Google Apps system. Users submit requests to the application, the application interprets these requests and then makes requests to Google resources as necessary.The point is that users, who normally do not have permissions to access/modify the google apps resources, will be able to use this application to do so in the limited ways that it allows.
My problem lies in the apparent fact that the OAuth2.0 authorization flow seems designed to allow third party client applications to authorize themselves as the user and access/modify the user's google resources, rather than a global administrator's. In other words, a normal API key type deal. Unfortunately it seems that Google's AdminSDK will only work with OAuth2 authorization.
Is there a way to use Google's AdminSDK API with OAuth2 (permanent access token, maybe? API key?) to do what I want? Or is there a different API I should be trying? The now-deprecated Provisioning API seemed to be able to do this.
I feel like there should be a way for the application to just pull something out of a secrets.json or secrets.yml, include that in the API authorization request and have Google servers recognize and grant access to the application without the user ever needing to see what's going on.
For the record I'm using Ruby on Rails, though I don't think that affects the question very much.
My understanding of OpenID is that it provides a way to have one site contain all your identity & peripheral info, but to let other OpenID-compliant (and user-trusted) sites re-use that info for identifying and authenticating the user. Essentially it minimizes the number of logins credentials (usernames & passwords) a user has for the internet.
My understanding of OpenSSO is that it allows you to sign-in to one site and automatically log-in to all other sites that the first site trusts. Essentially it minimizes the number of times a user has to log in to these different sites.
My understanding of OAuth is that it allows users to grant 3rd party sites certain access to their information located at one particular site. Essentially, like OpenSSO, it minimizes the number of times a user has to log in to these different sites. The different with OpenSSO is that OpenSSO logs the user into all the participating sites at once (with full privileges turned on), whereas OAuth grants finer-grained access to these participating sites.
So, first off, if anything I have said is incorrect, please begin by correcting me!
Assuming I am more or less correct, then I have the following questions/need clarification on the following items:
When would I choose OpenSSO over OAuth - just when I want to restrict access that the other participating sites have when a user logs in to one of them?
Are their different security risks for each of these technologies that I will have to consider and integrate into my app - or are they considered secure in and of themselves (basically can I rest assured that if my app uses them that my app is not open to any new attacks)?
Since these technologies are so closely related its hard for me to see the whole "forest through the trees" here - thanks in advance!
Not really the right comparison to be making. OpenID & OAuth are protocols, OpenSSO (now OpenAM) is an implementation of those and other protocols (SAML, OAuth, etc)
Generally speaking, the protocols for OpenID and OAuth are similar even though they originated with different use cases in mind. Today there is a lot of convergence around OAuth 2.0 for both federation (authentication) and authorization cases. The next generation of OpenID called OpenID Connect is built on top of OAuth 2.0 and precursors to this are already in place at Google, Facebook, Twitter, etc...
As for security, there are always some risks, particularly with implementation errors. Pick a good implementation and read the specs so you understand what the risks and countermeasures are.
OpenSSO is for you to log into one site and be logged into multiple sites.
OAuth lets one site extract your data from a second site (pull your tweets or facebook statuses) without the first site having to know how to log into the second site.
I'm working on an appengine app which uses OAuth. Naturally, I'm dealing with multiple versions of the app simultaneously - a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider's site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app - this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven't seen it).
More generally, what standard approaches are used to deal with this - my guess is register multiple apps and have logic in the app to determine if it's in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I've seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you "register" multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don't.
From an API provider's perspective your app is simply an app using the APIs. Usually there is no such thing as a "staging" API, which does not deal with live production data. Whatever it is you are testing, you are testing it on live data right?
If you are able to register several different applications with for example different callbacks then I think your problem is pretty much solved. My view is that it should be the consumer's responsibility to keep these things separated.