Is it possible (or is it planned soon? roadmap?) using the Trusted Application API to get the presence changes from users of an O365 group? (as in UCMA).
With webhooks instead long polling(UCWA)?
What is the webEventChannel ( notifications) in Trusted Application API (github).
What kind of notifications we can get via the webhooks?
Also would be able to use the Trusted API to change the presence of other users as in UCMA? without user credentials. as trusted application endpoint?
Related
I have a website and an API. The website allows anonymous people to browse the catalogue, but you must be logged in to post stuff.
I have built an API that exposes the same functionality. The API is used by a mobile app we are developing, but we are also going to allow other developers to use the API (i.e. it's publicly documented). The entire API is currently requires OAuth (2.0) authentication. To prevent abuse we use rate-limiting per OAuth client-id/user-id combination.
Now a new requirement for the mobile app has come down: The app should allow anonymous users to browse our catalogue. I am not sure how to implement this, without opening up our API to abuse.
Anonymous OAuth access
The first problem is allowing anonymous access. If we still want the entire API protected by OAuth then our mobile app will have to use the client-credentials grant type (posting a client-id and secret key). But we would have to store the client-id and secret in the app itself. This is not secure since it can easily be reverse engineered.
Alternatively, we could use dynamic client registration. As soon as an app is installed, it registers with an (undocumented) API to create an OAuth client for itself. Problem here is, how do I protect the client registration endpoint? A secret key again? Plus, this leads to a large amount of OAuth clients registered.
Remove OAuth from public endpoints
Alternatively, we could remove OAuth from the public endpoints all together (i.e. browsing the catalogue) and only require OAuth for posting stuff or managing an account. But how would I protect the API from abuse then? Without OAuth I cannot rate-limit based on client-id.
I am not sure that rate-limiting based on IP address would work. We expect many mobile app users and I fear that crappy (Moroccan) mobile telecom providers are NAT-ing a large amount of phone users behind just a few IP addresses. This would quickly exhaust any rate-limit that we set.
Is this correct? Or can I safely rate-limit on IP address for mobile users?
Alternative security mechanism
I could also implement a different authentication mechanism alongside OAuth. Something that allows our mobile phone app access to the API, which can distinguish (and rate-limit) different phones/users but which is safe from people just extracting a shared secret key from our mobile app binary.
Any suggestions on how to allow anonymous access to my API but still rate-limit effectively?
Since, the mobile app is installed on a device, if you configure a secret, then that secret will be common for all installations of the mobile app. Thus, derailing the purpose of a secret.
You should do dynamic registration. Here are the steps
Developer preconfigures the the following information with a trusted authority.
{
"software_id":"COMMON_VALUE_HERE",
"software_version": "OPTIONAL_BUILD_VERSION",
"client_name":"HUMAN_READABLE_CLIENT_NAME",
"client_uri":"OPTIONAL_FOR_CLIENT_CREDENTIALS",
"logo_uri":"OPTIONAL_FOR_CLIENT_CREDENTIALS",
"tos_uri":"OPTIONAL_TERMS_OF_USE"
}
The trusted authority generates a "software_statement" in exchange of the information that the developer provided. This contains the information that is constant for all installations of the native app.
After the app is installed on the user device, the app contacts the Authorization server for dynamic registration. The app posts the following to Authorization server
{
"redirect_uri" : "OPTIONAL_FOR_CLIENT_CREDENTIALS",
"scope": "SPACE SEPARATED SCOPES",
"software_statement": "MANDATORY"
}
The Authorization server verifies the information present in the "software_statement", generates and returns back a "client_id" and "client_secret" that are specific to the particular installation of software.
The client calls "POST" method on token endpoint with the newly received "client_id" and "client_secret", and receives an "access_token".
The client uses the "access_token" for accessing the "protected_resource".
The source of my answer is "oauth 2 in action" by Manning publication.
I have an API with the following method:
https://api.example.com/services/dosomething
I am providing this service to three different mobile apps, each one with hundreds of users. When a user logs in in the mobile app, a call to my API needs to be made.
I know that providing each one of the three mobile apps a different API Key and doing a HTTP Basic Authentication with it is not secure, since the API Key would be unsafely stored in the device an anyone can take it and make bad use of it.
The approach of OAuth2 doesn't work, since I only have information of my three customers, not their hundreds of users.
What is the best approach to secure the calls to my API on mobile?
In your case, your approach with OAuth2 is good: mobile apps (clients) receive delegation from resource owners (your users) to call protected resources on a resource server (your API).
You only have information about your clients because OAuth2 is not dedicated to authentication of your users but authorization of you clients.
The clients are identified with a client ID. In your case and if you want to know which client calls your resource server, then each client should have a dedicated client ID. You may also identify it using other information such as the IP address or a custom header in the requests it sends.
If you want to know who your users are, you should implement the OpenID Connect extension. This extension works on top of an authorization server based on OAuth2.
The authentication of the user is performed by the authorization server. An ID Token is issued with information about the user. The client (or mobile app) does not have to get or store user's credentials.
There is an excellent video where the both protocols are explained (especially from 4:44 to 11:00).
We are developing an inhouse application, which will be distrubuted via Mobileiron. I can get the active-directory/mobileiron user name and device id from mobile iron. What i need to know is, when a web service call comes to my api, i want to make sure the call is coming from a client who is logged in to my app using mobile iron. I have no idea how to do this. My manager doesn't want to use Kerberos for single sign-on and all the documents i could find contains messy information.
Can someone please show me the way in some detail? do i need to use certificate or Sentry? How should i do that?
I am running out of time so any help would be appreciated.
From my experience, you do not need to use Kerberos. You can use certificate-based authentication and have Mobile Iron configured to return the certificate. If you are using AppConnect API you can have the base-64 encoded cert (.p12) and password provided as part of the configuration object (via AppConnect.sharedInstance().config), which would then be passed along to the server for authentication. The LDAP user's email is embedded in the cert, so the server can associate it to a user.
There's also the option of using "pass-through" authentication which basically trusts the client is authorized. Not the safest option.
I have a user provide me the organization he wants to Sync with our system. We create the hooks afterwards for each App of the Organization.
The only workaround I found is to ask for each App ID and Token or the username authentication.
How can a Webhook be authentified to have the right to get items from all Apps at the same time? (like a server-side authentication)
There are a couple of options: The best is to contact Podio support and get an increased trust level for your API key. Then app tokens can be retrieved through the API and you can fully automate hook creation.
The alternative is to create a user that's a member of all spaces which you can authenticate as using password-based authentication.
I'm in the middle of creating a RESTful API for a personal project and I've been reading about api authentication. It is probable that I just don't understand what different things are for. What is OAuth for? What are API keys for?
Main Question
Why can't I just have every request use HTTPS and use sessions/cookies?
If users will access your API through an application you own or control, then HTTPS and user authentication/authorization is ok.
However, if you want to allow applications created by other developers to access your API OAuth and API keys allow you to control how these third party applications use your APIs.
API keys: By assigning individual api keys to each application, you can identify the application sending the request. You can use this information to track or limit what the application can do with your APIs.
OAuth: If the 3rd party application needs to access sensitive data owned by users or perform an operation on their behalf, then you want to ensure the user is ok with this. One way you can do this is to require the application to pass the user credentials with every request. However, this is usually not a good idea as you don't want users to reveal their usernames and passwords to third parties. Here is where OAuth comes to the rescue as it allows users to provide third parties with limited permissions to access your API on their behalf.
SSL is adequate for this if:
you require a client certificate
the application obtains the client certificate
the application validates it against a list of acceptable clients
the application records which client executed the transaction.
Without all that you're just accepting transactions from just anybody, which is the problem that OAuth is solving.