We have a third-party Azure AD application which uses the Microsoft Graph API. This application has not been changed in Production for around 2 months, and we have not had any issues so far.
Since this morning, I am unable to login to the application due to HTTP 429 responses on requests to the Office 365 Graph API. This is happening to requests on both /messages and /people endpoints. See below screenshot of developer console:
Would someone be able to advise if there have been any recent changes to the throttling limits on the Graph API?
I don't understand why this would suddenly start happening when there have been no production changes to our application for months.
You can find information on throttling at Microsoft Graph throttling guidance. Without knowing how your application is authenticating or how often the endpoints are called it is difficult to asses exactly what is happening here.
More concerning here is the use of the /beta endpoint in production. Using the /beta endpoint in a production environment is almost certain to lead to your app unexpectedly failing. While every effort is made to ensure changes to the /v1.0 endpoint are non-breaking, this is not the case for /beta. Breaking changes in that endpoint are to be expected.
Note: The APIs in the beta endpoint are subject to change. We don't recommend that you use them in your production apps.
Related
We have a working outlook app using version 1_1 on O365. We are testing this with an exchange on prem only setup but with azure AD hybrid. The graph API functions we need work within this environment thanks to testing on graph api exporer.
When we push the manifest to exchange either via the exchange admin portal or via powershell we receive an error relating to webapplicationinfo being invalid. We have this within versionoverride 1.1 and that within versionoverride 1.0
If I remove the webapplicationinfo section which includes the scope, this will import ok, but when the app performs the function to get the auth token it fails, for which I am sure because the scope wasnt authorised.
No where i can find that says on prem is not supported. I find a lot of reference to 2016 CU3 but nothing specific to on prem. Can someone assist?
Exchange 2016 Cumulative Update 3 (CU3), released in September 2016 for Exchange on-premises servers, adds support for REST API integration with Microsoft 365. If your app uses v1.0 of the Mail, Calendar, or Contacts API, you will now also find a seamless authentication and application experience in hybrid deployments, regardless of whether the mailbox is on-premises or in the cloud, provided that the deployment meets specific requirements.
See Use REST APIs to access mailboxes in Exchange hybrid deployments (preview) for more information.
I'm frustrated with Google's OAuth APIs. My use-case just doesn't seem to be covered by the available endpoints. I'm hoping someone with knowledge of the Google Drive OAuth APIs can advise me.
I'm developing a browser add-on. This means my app is:
Serverless. I don't want to have to maintain a domain and webserver for this project.
Open-source, so it's trivial to extract any secrets packaged with the code for anyone who can install the add-on. Therefore any information distributed with the add-on has to be considered public.
I want to add Google Drive integration so the user can store app configuration data on Drive so as to sync between devices (the WebExtensions browser.storage.sync API is not sufficient, because there's too much data). My requirements are:
The user should not have to log-in to Google Drive more than, say, once a month. Certainly not hourly, or each time they use the add-on.
This should work across multiple devices for the same Google Drive account.
If Alice authorizes MyApp to access alice#google.com, and Eve extracts the OAuth client ID/secret or other info from the MyApp source code, it should be impossible for Eve to access alice#google.com without knowing Alice's Google password.
None of the flows documented on the Google website seem to fulfill these two requirements. I tried the server-side, since I thought the refresh tokens would fulfill requirement (1), but it seems Google only issue a refresh token the first time I request one. After that I just get a short-lived (one hour) access token. So this violates requirement (2) because whichever device talks to Google first will be the only one with a refresh token.
I have the requirement that the signature of my Swift iOS app has to be checked.
I think it is only relevant for jailbroken devices as iOS checks the integrity by itself.
I couldn't find much on the web - most libraries/snippets have not been updated for 5 years.
My current approach would be to calculate the app signature (C-Code) and compare it with an array of signatures that have been loaded from the server. An array because to support multiple versions of the app.
Any ideas or comments on this approach? Maybe it is not relevant anymore for Swift?
Here are some resources that would inspire my solution:
https://github.com/olxios/SmartSec_iOS_Security
https://github.com/project-imas/encrypted_code_modules/blob/master/ecm_app_integrity_check/ecm_app_integrity_check/app_integrity_check.m
Your Current Approach
My current approach would be to calculate the app signature (C-Code) and compare it with an array of signatures that have been loaded from the server.
I need to alert you for the fact that in a rooted phone the attacker will be able to intercept your code at run-time and modify its behavior, this means that your logic to detect the signature is ok will always return true. They do this by using an introspection framework like Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Your Requirement
I have the requirement that the signature of my Swift iOS app has to be checked. I think it is only relevant for jailbroken devices as iOS checks the integrity by itself.
Well if this requirement have the intention of only protecting your app from running in a rooted device, checking the signature of the app is not enough, once the device is rooted, any app on it can be easily manipulated, as I already mentioned. Protecting an app from attacks on the device itself is a daunting task, and is like playing the cat and mouse game with the attackers, by trying to keep ahead on the game. You will need to use in app protections to detect if the app is running in a jail-broken device, have an introspection framework attached, is running in an emulator, if a debugger is attached, etc. This is a never ending game with the attackers and they have a huge advantage, they can dedicated all their resources and time to break your app, if its worth it for them, but you may not have the same human resources, time and money to invest in this game. No matter how you decide to play the game you can always resort to the Apple Device Check API to mark in the API server that a specific device is not trustworthy.
In case the requirement to check the iOS app signature is more in line with protecting the API server from receiving requests from an iOS app that is not the genuine one you have uploaded to the Apple store, then a better solution may be possible, and is known by the the name of Mobile APP Attestation. So if this is also in the scope of your requirement you should keep reading, otherwise just skip it.
Before I dive into the Mobile APP Attestation concept I would like to first clear a misconception about WHO and WHAT is accessing an API server.
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
So replace the mobile app by web app, and keep following my analogy around this picture.
The Intended Communication Channel represents the web app being used as you expected, by a legit user without any malicious intentions, communicating with the API server from the browser, not using Postman or using any other tool to perform a man in the middle(MitM) attack.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using Curl or a tool like Postman to perform the requests, a hacker using a MitM attack tool, like MitmProxy, to understand how the communication between the web app and the API server is being done in order to be able to replay the requests or even automate attacks against the API server. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the web app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the browser were your web app should be running from, with a real user.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the web app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise, you may end up discovering that It can be one of the legit users manipulating manually the requests or an automated script that is trying to gamify and take advantage of the service provided by the web app.
Well, to identify the WHAT, developers tend to resort to an API key that usually is sent in the headers of the web app. Some developers go the extra mile and compute the key at run-time in the web app, inside obfuscated javascript, thus it becomes a runtime secret, that can be reverse engineered by deobusfaction tools, and by inspecting the traffic between the web app and API server with the F12 or MitM tools.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?. While in the context of a Mobile App, the overall idea is still valid in the context of a web app. You wish you can read the article in full here, that is the first article in a series of articles about API keys.
Mobile App Attestation
The use of a Mobile App Attestation solution will enable the API server to know WHAT is sending the requests, thus allowing to respond only to requests from a genuine mobile app while rejecting all other requests from unsafe sources.
The role of a Mobile App Attestation solution is to guarantee at run-time that your mobile app was not tampered with, is not running in a rooted device, not being instrumented by a framework like Frida, not being MitM attacked, and this is achieved by running an SDK in the background. The service running in the cloud will challenge the app, and based on the responses it will attest the integrity of the mobile app and device is running on, thus the SDK will never be responsible for any decisions.
MiTM Proxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
Summary
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
Going the Extra Mile
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
Currently I am implementing an Ionic application that the front-end is on the mobile devices and the back-end is on the server. (So there is a connection latency between the device and the server) And my application is using the Google services (like Gmail, calendar, etc) by connecting to the Google API.
Currently the architecture is:
Device <==> Server <==> Google API
This is using the OAuth 2.0 server-side authentication. It works but the connection latency is way too long and feels like going back to the time when we have the dial-up internet connection.
I tried to use the OAuth 2.0 client-side authentication, which is:
Device <==> Google API
This is faster but it has 2 problems:
Even though Ionic packaged the front-end code into an application, I still have concerns that the rule "Everything in the front-end is visible to everyone" stays. (Did not find an evidence to prove or disapprove this hypothesis)
Google API OAuth 2.0 only issues flows to the client-side authentication, and flows expire very often, I don't want the user to grant the permission again and again.
So, I was wondering if it is possible to do the following:
Use the server-side authentication to store keys/credentials (I'm using Django as the back-end, which is Python) and the front-end gets keys/credentials from the server and proceed Google service using JavaScript codes.
I know this is late to the party, but I'm going through this now. I think there are 2 ways to set this up, but neither are perfect.
Use server-side flow to authorize all the scopes you'll need on either the server or the client. When the token is obtained, pass it to your client. The down side is that the client now has a token that has access to more APIs than needed.
Create seperate authorization flows for both the client and server. This would mean the user has 2 authorization prompts, which is no good. The good thing about this approach is you could ensure the client has limited scopes, but the server could still handle the larger tasks (moving Drive files, sending emails, etc.)
In my case, the client would just need read access to the Contacts API, whereas the server needs full Drive access.
If anyone finds a combination approach, where only 1 authorization is needed, but the client and server have seperate scopes, that'd be the ideal situation.
I configured an application on AzureAd to be multi-tenant, I chose to require all the permissions for Windows Azure Active Directory and Office 365 Exchange Online.
I can get a user to grant permissions, get access tokens, refresh them, OAuth works for me. I always used the "common" keyword instead of the tenant ID, because my app is multi-tenant.
Now, I would like to have (CRUD) access to a user's Mail, Contacts and Calendar with this token. Here is my problem: I am completely lost in all the possible API endpoints. Should I use: graph.windows.net, outlook.office365.com, graph.microsoft.com? This page seems to suggest that graph.microsoft.com is the Swiss army knife that would serve my purpose, but somehow I cannot find a doc that allows me to find the info I'm looking for. Plus, it seems under development and maybe too incomplete for what I want.
If I make queries against outlook.office365.com, I've got a 401 error.
If I put my access token in this token analyzer, it seems healthy although the scope field only shows the permissions I set in the AzureAd portal for Windows Azure Active Directory, not Office 365 Exchange Online.
I am kind of lost, any help would be welcome...
You have a choice:
Call the separate service apis - Your problem is that you acquired a token to call AAD, and then tried to use that to call Outlook - you need to make a separate call to acquire a token for outlook.office365.com through ADAL or through the token endpoint directly. The token acquired for AAD Graph can ONLY be used against AAD Graph. Similarly the token acquired for Outlook can ONLY be used against Outlook APIs.
Just to clarify - Azure AD OAuth can protect/secure multiple web APIs, including O365 APIs, Azure AD Graph, Azure Resource Management APIs, your own APIs and the new O365 unified API. In the first access token request, you specify the first resource you want/need to call. It doesn't have to be AAD Graph - i.e. it's not the default AFAIK. Based on what is consented to, you have the ability to request additional access tokens using the (multi-resource) refresh token. Vittorio's blog post which you link to in your comments does a great job explaining this.
Call the O365 unified API (which is in preview) and IS documented. See below. The beauty of the unified API is that you only need to acquire a token to call graph.microsoft.com and ALL the entities on that endpoint are available to you AND more. It removes the siloed nature of #1, and the requirement to get and manage multiple access tokens to call these different API endpoints. However #1 is currently GA, and the unified API is preview only at this time.
For more on #2 please see https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-overview and search for "unified" in the list of samples here: https://msdn.microsoft.com/en-us/office/office365/howto/starter-projects-and-code-samples
We are working on improving the unified API documentation. If you are making pure REST calls, then I recommend starting out with the API explorer (and try things like https://graph.microsoft.com/beta/me/events and https://graph.microsoft.com/beta/me/messages to get your calendar events and mail messages), OR the API sandbox (which can show you JS code snippets, and allow you to test your own easily enough). As you can see on the REST examples, to access mail and calendar features in the unified APIs, you should be able to swap the service roots from Outlook to the unified API ie - https://outlook.office365.com/v1.0 -> https://graph.microsoft.com/beta. On the JS sample - we will be adding more capabilities here and additional samples.
NOTE: Personal contacts available in outlook.office365.com are not available in the unified API yet.
Hope this helps