I have read IdentityServer documents and see that aims to manage resporce authorizaiton. And I want to learn that can I use this for my enterprise Api? For example I have Finance and IT department controllers in my API. Should I create 2 scopes for them? If I do, after the login screen will show permissions screen. Check or Uncheck Finanace and IT checkboxes. Can I hide these scopes from user?
Scopes model resources, and then you can configure clients to be allowed to request access to those resources. So one reason you break APIs into different scopes is so you can configure which clients can access which APIs. So if you don't want your Finance apps to access the IT APIs, then yes, sounds like those would be two different scopes.
As for showing consent to the user, you can disable the entire consent screen per-client in the Client configuration. This makes sense when it's your client app accessing your APIs on behalf of your users (IOW everything is first-party).
Related
Facebook provides an OAuth authentication system for third-party apps but they appear to not provide any fine-grained user management capabilities.
This seems like a security problem. I need to be able to:
Disable delete unused accounts
Disable or delete abusive users
White list users for early access to a new app.
But AFAICT FB provides no tool to do this.
I can probably hook of of the OAuth ID and put an entry in my database for the first two requirements, but I can't figure out how to white list Facebook users.
Google is unhelpful because all the results are about let users manage applications their user account is attached to, and nothing about allowing apps to manage what user accounts they are attached to...
Usually is a bad idea to delete or disable unused accounts, because maybe user was inactive for a long time, this doesn't mean the user deleted or disabled his account.
On the other hand, you can't avoid malicious users join your app via facebook authentication. What you can do is to detect suspicious activities with your own implementation (after Facebook accept them to join your app), and suspend, block or disable those accounts on the server (blacklisting them), after the user has joined client-side and sent the required access-token (optionally request the ID) trying to be accepted by the server.
Whitelisting users may depend on the requirements of your application, you can check profiles data and reject those that doesn't provide the requirements that your app needs (remember to ask the user for the fields that your app requires, like public profile, pictures, etc; these must be accepted by the user before signing in).
Here's how you white list users for an app on Facebook:
Keep the app in Development mode
Add users from your friend network in the Testers role
When you are comfortable, open your application to the world.
AFAICT you cannot white list when your app is published, but that's the point of publishing. Also the whitelist is not a request-grant method, it's invite only.
The other requirement to delete or disable users you must handle yourself in your database. You would tie the user's status to the FB's unique ID.
I am currently developing an app to manage my clients' Facebook AdAccounts. The usual workflow is to, among other things, individually authorize each AdAccount I want my app to have clearance to, by use of the dashboard at https://developers.facebook.com/apps/. The usual path is you click on your app -> Settings -> Advanced and scroll down until you find the Advertising Accounts panel. Then you click on the top-right button called Ads API and use the modal to manually include the Ad Account IDs to which you want to have API permissions.
However, this app is intended to manage dozens or hundreds of Ad Accounts, and it's supposed to manage this programmatically, as per the app's requirements. I looked all over the place and couldn't find any endpoints or wrappers in any programming languages to do that and I've been stuck for a few days now... so I was wondering if you guys could help me somehow.
That place you're referring to only applies to apps with 'Development' or 'Basic' access to the API
If you apply for and receive 'Standard' access, that dialog isn't necesssary, and your app can make API calls on behalf of any user who grants your app the ads_management permission
I.e once a user grants your app access to their accounts, you use their access token to access any accounts they are able to manage, on their behalf; it's only in the lower access levels of the API you need to provide a fixed list of Ad Accounts you'll be managing
Take a look at the Business Manager APIs. They're intended for the use case you mentioned (managing other accounts).
https://developers.facebook.com/docs/marketing-api/businessmanager/v2.6
I have a Facebook App that uses only one permission: ads_read. What is the simplest way to make it work when it comes to authorization? I see that there's an option to authorize particular ads accounts to the app, but is there any easier way for read-only access? I will have multiple ad accounts there and I am the admin of all those. I would like to be able to use them all without authorizing them separately from the Facebook GUI.
Is it possible?
You probably have "Development" access to the Ads API, if so, you need to do this manually at the Facebook App settings (Advanced option). The limitation for this is that you will be able to add your App only to other Apps that you admin.
If you want to allow other Apps you don't manage to use your App, you need a higher level of access.
You can see more info about access level here:
https://developers.facebook.com/docs/marketing-api/access
You can request a higher access level using this link:
https://www.facebook.com/business/standardadsapi
I hope it helps.
I have a web application that's going to be available for all users on my google domain.
Is there a way of allowing the application to manage user's emails, calendar, etc without requiring the user authorization using the fact that all users are part of the domain?
You will need to have a look into Google Apps 2-Legged OAuth APIs, they will allow you to access/manipulate users data without their authorization.
You can find the list of available 2-Legged OAuth APIs here.
Unfortunately you will see that you cannot do as much with the 2-Legged API as you can with the 3-Legged API. However, 3-Legged OAuth requires the users consent at least once.
Is OAuth sensible to use when the user account info (user id's, passwords, roles, etc) is going to be maintained in our own back-end and when there will not be any sharing of resources with other sites? Or is sharing the whole point of using OAuth?
Background:
I'm working on developing an enterprise SaaS product and we are creating a RESTful API to be used by our front-end applications. Consumers of the API will be browser and native smartphone (iOS & Android) applications that we develop. Since we'll be supporting multiple client types, it makes sense to create a RESTful API that all our client apps can consume.
Naturally we need to secure this RESTful API. We are considering authenticating using HTTPS / Basic Auth but we are aware of some of the well known drawbacks to this approach.
Some quick research shows OAuth is highly recommended. But most of what I find with OAuth is in the context of authorizing web sites to share information on behalf of the user.
Any info if most welcome.
Good question, and we're having a good discussion on this over at API Craft:
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
Here's the answer that I posted there:
I think this is a good use case for OAuth, actually.
First of all, with OAuth your mobile app can store an OAuth token on the client rather than the user's "real" password. So, you can have the app automatically "log the user in" by getting an OAuth token without having to store the actual password on the device. If the user loses the device or if it's compromised somehow they (or you) can wipe the OAuth token without requiring that the user change the password and blow away other things that they might be doing with your API. There are similar examples for an Ajax-style web app but it depends more on the specific way that you build the client.
Second, the OAuth token is associated with a unique key that identifies the app that is making the API call, and that in turn identifies which developer built the app. That gives you options like tracking usage by application, turning off an application that might have been compromised without disabling the whole API, and if you ever want to open access to third parties or partners who build apps for your API, you can offer different levels of service to other customers.
Third, your IT security people will be happy if you tell them that you never store a password on the user's mobile device or stash it somewhere in their browser.
Fourth, you have the option of browser-based login for the mobile app. That means that the mobile app will never see the user's password, and also that if you want to implement two-factor security or something like that, you can do it in the login screen without changing the mobile apps. Now, the downside is that the user sees a browser window pop up. That's why OAuth gives you a few different ways to get an access token for an app, so you can choose whether you need to have browser-based login or have the user enter their password directly in the app.
Fifth, how do you know that your API will only ever be used by your own apps? If you use OAuth now then you will have an easier time making that transition later.
Yes, this is a very good fit for OAuth. You can still use HTTP Basic over SSL during the handshake for authentication. The output of the OAuth handshake will be a token which can then be used to consume the API. This way, the application does not need to store the credentials and tokens can easily be revokes with minimal user impact.
OAuth 2.0 defines a number of different grant types for accommodating different situations. It sounds to me like the 'implicit' or the 'resource owner password credentials' are the most appropriate but you may want to consider each carefully.
You should not implement this directly in your API but use infrastructure to delegate the OAuth support and token management on behalf of your SaaS API instead.
Take a look at
http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/
and
http://www.layer7tech.com/products/oauth-toolkit
Hope this help,
-fl
I implemented an OAuth for Django nonrel with piston to expose my APIs to consumer. There are a number of kind in OAuth(2-legs 3legs).
Generally, supporting OAuth is quite a bit challenge. You have to obtain the request token, authorize it, store the access token to sign every request you want to authenticate.
Advantages
- You don't have to send username and password everytime, secure.
- Enable third party to consume your app.
Disadvantages
- Make 2,3 round trips to authenticate.
- Complicated to implement it by yourself.
I'm pretty sure that you can find a number of library that allow you to:
- Expose your Api and support OAuth. E.g Django piston.
- Sign your requests by adding headers to them. E.g Oauth-signpost.
OAuth is only a token and the requesting App will issue one. You can read more in pingidentity.com where there are several webinars on this topic(cloud identity and user provisioning) as well.