Featured in AI, ML & Data Engineering

In this article, author shows how to use big data query and processing language U-SQL on Azure Data Lake Analytics platform. U-SQL combines the concepts and constructs both of SQL and C#. It combines the simplicity and declarative nature of SQL with the programmatic power of C# including rich types and expressions.

Featured in Culture & Methods

The book Agile Leadership in Practice - Applying Management 3.0 by Dominik Maximini is an experience report of the agile transformation journey of NovaTec. Maximini shares his experiences from applying principles and practices from Management 3.0, success stories, failure stories, and learnings from experiments.

Featured in DevOps

Yuri Shkuro presents a methodology that uses data mining to learn the typical behavior of the system from massive amounts of distributed traces, compares it with pathological behavior during outages, and uses complexity reduction and intuitive visualizations to guide the user towards actionable insights about the root cause of the outages.

George who has developed against myraid web service API’s, observes that each one requires a different authentication mechanism.

I'm tired of wasting brain cycles figuring out whether vendor A requires you to sign your query before or after you URL encode your parameters and I am fed up with vendors who insist on using interactive user credentials to authenticate API calls.

He outlines the rules for designing authentication schemes for REST API’s. “Let's just be blunt: if you aren't encrypting your API calls, you aren't even pretending to be secure”, He says,

1. All REST API calls must take place over HTTPS with a certificate signed by a trusted CA. All clients must validate the certificate before interacting with the server.

Through the use of certificates signed by a trusted authority, SSL also protects you against "man-in-the-middle" attacks in which an agent inserts itself between client and server and sniffs the "encrypted" traffic.

If you are not validating the SSL certificate of the server, you don't know who is receiving your REST queries.

2. All REST API calls should occur through dedicated API keys consisting of an identifying component and a shared, private secret. Systems must allow a given customer to have multiple active API keys and de-activate individual keys easily.

The first important thing is that a system making a REST query is NOT an interactive user. […] REST is authenticating a program and not person, it allows for stronger authentication than human user ID/password schemes allow.

The second part says that each REST server should support multiple API keys for each customer. This requirement makes it simpler to isolate potential compromises and address them when they happen. […] When an application is compromised, you also need an elegant way to roll out replacement API keys.

3. All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private credential as the signing token. Signing should occur before URL encoding the query string.

In other words, you don't pass the shared secret component of the API key as part of the query, but instead use it to sign the query. Your queries end up looking like this:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

The string being signed is "/object?apikey=Qwerty2010&timestamp=1261496500" and the signature is the HMAC-SHA256 hash of that string using the private component of the API key.

He admits that in most RESTlike and RESTFul API solutions that authentication is most certainly a secondary consideration. However, in the conclusion of his article he urges readers "to follow someone else's example and not roll your own authentication scheme”.

What about browser clients ?

Your message is awaiting moderation. Thank you for participating in the discussion.

In my company we write a javascript client that issues REST calls via AJAX to the server and gets the data in JSON form.some of these calls are in global pages which do not (by product decision) require users authentication.however, i woould like to know if my own client is trying to get info or some bot that somebody wrote.how can i generate a key in javascript environment where my code is out there are can be copied and used ?Thanks,

REST security is about more than OAUTH and SSL

Your message is awaiting moderation. Thank you for participating in the discussion.

Authentication and authorization are only a small part of what you need to consider. Many of the known vulnerabilities relating to web applications apply very much to REST apis. You have to consider input validation, session cracking, inappropriate error messages, internal employee vulnerabilities and so on. It is a big subject.