We have a requirement to call other APIs other than graph(like Dynamics, Power Automate etc.,) from our Add-in. All examples in Office Add-in Samples suggest to use bootstrap token and then exchange it to get tokens for subsequent APIs and make calls on the server. This forces all communication from our Add-in to be proxied via our server. This can be a unncessary performance bottle-neck. Can we not send the OBO tokens back to our client side Add-in and call other services directly from the client? Is there a known security issue with this approach?
The "received wisdom" about whether access tokens should be sent to clients or stored on clients has fluctuated over the last 10 -15 years, but in recent years the pendulum has swung pretty decisively to the idea that access tokens should not be on the clients. Client-to-server communication is much more vulnerable than server-to-server communication, because there are a wide variety of well-known ways to attack clients and trick users. At the same time, bad actors don't know when server-to-server communication is going to take place and it is much harder to get access to the server computers on either end of the communication.
Related
I currently have a mobile application talks to a GraphQL API service which terminates SSL and then proxies requests to gRPC services. The gRPC services only talk to each other via gRPC.
This system works okay but writing all of the boilerplate to plumb the gRPC APIs through the GraphQL layer to the client is tedious and can be error prone.
I’ve started exploring the idea of talking directly to the backend via gRPC as the tooling has improved substantially over the last few years.
One issue I’m still wondering about, though, is the best way to disambiguate APIs only meant to be called internally by other services from those callable publicly by the native client.
There is also a third category, “hybrid” APIs where it can be called either internally or externally.
Examples —-
Internal: Sending an SMS via Twilio
Public: Log in to account
Hybrid: Update whether an inbox item is read (both from the app when opening a conversation and on the backend when a message is sent)
One option I thought of was an interceptor that passes along a context to indicate if the request is internal or public and use this in the code to return an error or perform additional validation on public requests.
Another option is creating an API service which is still gRPC but fulfills the same purpose as the GraphQL API service.
A third option is disambiguating public and internal services at an organizational level which might require duplicating some APIs that exist for both.
Are there other options I’m unaware of? How have you tackled this issue?
I have WCF client on my WPF app. WCF client is generated with asynchronous operations.
I am doing parallel calls with awaiting to Tasks.
I noticed some delay on data getting and when sniffed traffic with Microsoft Message Analyzer, noticed, that for some calls I did 2 request were sent with about 500ms interval but got one response.
In my app I have only one call.
Question is why 2 underlying calls were sent by WCF client?
P.S. I checked by hosting service under IIS and IIS express. Same result on both cases.
Your issue here is not with your client or service, but with your analysis tooling.
Microsoft Message Analyzer is designed for low level network monitoring.
Higher level protocols such as SOAP will almost certainly utilise more than one network message per logical call.
WCF supports lower-level protocols such as UDP, where the number of messages on the network may bear more resemblance to the number of service calls you make, but this is buy no means garanteed.
As such, the service itself is the ultimate arbiter of how many logical service calls it has received.
If you do need to analyse the underlying traffic, you could also look at WCF Tracing, which will group network calls together into "conversations", that resolve to a single instance of a client-service request/response pair.
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
RESTful services are plenty like the one below which is weather forecast related.
http://api.openweathermap.org/data/2.5/forecast?q=chicago,us&mode=json
However, why aren't there services like
ws://api.openweathermap.org/...
with some documentation about what messages a websocket client can expect to send and receive bi-directionally over a single connection?
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
Maybe because websockets were not created for that? They came from the HTML5 initiative and were created to replace Ajax interaction between a browser and a web site for real time web applications. No more polling, long-polling, streaming, flash sockets, or any other HTTP hack to make a server push data to the browser. Webocket is the real thing.
Most web services now follow a request/reply pattern while the websocket is still a maturing technology. Give it time and services will appear, services that actually need the capabilities of websockets and not use them just because "there is a new kid in town".
As a final note, here is something for websockets emerging from Microsoft.
I hope to create a web server that can give some extra facilities for SMS Service Providers. Can I send SMS through internet? If its possible then, Are there any libraries for Send and Receive SMS over the internet?
There are many different options to send SMS over Internet, but most popular are the following:
Connecting to SMSC of mobile carriers directly (usually via SMPP protocol).
Connecting through some SMS aggregation service like Clickatell mentioned in previous answers.
Choice between these options depends mostly on non-technical issues:
Required coverage (mobile carrier will provide only messaging inside it's network).
Premium Rate billing possibility (this requires closer work with carrier).
Well, price too... :-)
Technically most popular options are:
Specialized protocols like SMPP (Short Message Peer to Peer).
HTTP based protocols provided by SMS aggregators.
If you need unified solution, I recommend to use Kannel open source SMS gateway that support many popular transports (SMPP, CIMD, UCP, HTTP, etc).
You've got www.Nexmo.com www.tropo.com www.twilio.com www.smsified.com ... and so on...
You can use http://www.clickatell.com/ which gives you a few options such as sending SMS one by one, or by using bulk files such as XML.
I found the clickatell API to be really usefull and easy, I managed to add SMS capability to an existing website in a few hours by creating a simple class to wrap up all the methods.
One thing to remember though this is not going to be free for you, there will be costs involved depending on where you send the text to, and where you are based.
You can send SMS programmatically through TheTexting API, They provide cheap rates and their service is really good.
Full disclosure: I work for company that makes this product.
We're building a set of external web services to be consumed client-side (using jquery/AJAX) by visitors to our site. The web services need to be publicly available but we'd like to limit access to site visitors.
Importantly, the site in question sits behind a CDN and we cache page content for 24 hours; AJAX requests would preferably be cached as well but I'm conscious doing so will limit our authentication options. Our visitors access the site and services anonymously.
What are some standard "patterns" for authenticating client requests? I'm not dealing with confidential data per-se but do want to deter other users/sites from hijacking these services for liability (think data distribution) and performance reasons.
I'm thinking of a shared secret that's refreshed daily and used site-wide by all clients; any web service request would include the secret. Pretty basic but are there other, better ways for the service to detect the caller's origin in a manner that can't be spoofed?
If the threat to your web service is related to someone automating the client calls, you can implement rate limiting on server side. As you rightly mentioned, client can be required to provide key for each request. Alternatively, if only mortals are going to interact with web service, you can also implement Human Interaction Proof like Captcha etc. One thing to make sure is that "key" which will be used by client needs to given in controlled manner. I once came across a system which basically gave away unlimited keys - this means that automation control will be ineffective as an attacker can request as many keys and make unlimited calls. If you are limiting using IP address, make sure that you throttle requests on network part of ip address (A.B.C.X) as host part (X) can change (when users are behind proxies) If your clients are anonymous, the best/closest "identifier" is indeed address.