Securing Web Services

Nowadays almost all subsystem require to expose or consume data to/from other subsystems & yes, this is outside firewall or VPN. It can be other servers, mobile apps, wearable apps, IOT app or anything else. Exposing the data outside the network or cloud firewall is a very important decision. This became big responsibility for an organisation to make sure all data remain secure as well as rightly accessible. There are three aspects of security from WS point of view – message security, authentication and authorisation. In this article we will talk about first two. Let’s check some thoughts on these aspects.

• 1. Confidentiality-An approach to make sure all the communication remain confidential. Only client & server should be aware with message content.  There are multiple approaches at different level to maintain confidentiality.
  • SSL– It will add first message level encryption by implementing the same. Implementing client key on WS client will ensure that only authorised client can make successful call to server. Client i.e. mobile client can load the security certificate in the payload. Server can be configured with the approach to not to accept any one who is not signed with right certificates. Only challenge in this approach is to securing client key. There are multiple ways to do that; but it is not focus area of this discussion.
  • Message Encryption– Apart from de-fecto SSL approach. There are multiple approaches to encrypt the message content. That depend on use case and type of data transported to or received from server. But most of the cases putting client side SSL will address the need.
• 2. Authentication– It will very important to authenticate & authorise the users for request coming from different machines. It can be normal day to day request or it would be simple brute force attack. It become quite interesting to make sure rightful authenticated request. Here are some abstract approach to start with.
  • Basic Authentication– This is easiest and fundamental aspect to securing web services. A simple user name and password is put in HTTP header with Base64 encoding. SSL will make sure that; credentials wont be decoded.
  • Auth 1.0 or Auth 1.0a– This is signature based protocol. Token signed from client and shared to server will be decrypted and verified. Basically it is cryptographic signature. It may use SHA-256 etc.. This approach is well tested and widely used across the glob. By following this approach user can eliminate the need of SSL in first approach. However it comes with extra processing overhead of generate & signing a key, along with complexity.
  • Auth 2.0– Auth 2.0 spec has kept many decision on implementor. This makes this approach diversified, flexible and of-course secure. Lots of tech pioneers i.e. Google, Facebook, Github adopted this approach. Many standard programming frameworks provides inbuilt Auth2.0 supports. In Auth2.0 control of authentication will completely reside on server, nothing is exposed to client except couple of parameters. That does not play significant role in authentication, compare to earlier approaches. Here are the steps for Auth2.0 authentication
    • Naming Convention- User – Resource Owner, API – Resource Server, Third Party App – Client. So process is , resource owner will try to access from resource server through client.
    • Step 1 – Creating App – User need to register an app, as one time process, only basic information require to share i.e. Name, website, logo etc.. For custom restful development this step can be eliminated by hardcoded values.
    • Step 2 – Requesting – when user make a request, it redirect to Auth2.0 server (or process), it do the redirection to different URL. It is advisable do to under SSL to prevent accessing direct authentication URL. This become very crucial for various DDOS attack for authentication to prevent accessing Auth URL.
    • Step 3 – Authenticating – Auth2.0 server will verify few simple things i.e. Authorisation code, implicit (source i.e. Web, WS, Mobile etc.. ), user credentials, client credentials (application client key, if provided). These parameters are used and some of them can be optional.
    • Step 4 – Response – Based on above parameters, a response can be generated. It return access status true/ false and key for subsequent request for particular session.
  • Custom Authentication– There are multiple permutation and combination for authentication based on approaches or Auth 1.0a and Auth 2.0. We at 9series has observed and created many different such authentication mechanism.

Concluding above approach we think that SSL is fundamental need for any WS communication in confidentiality section. While Auth2.0 is widely used but many cases custom authentication is required.

We at 9series believes that, every different use case have different need for security. As it require to match with organisation belief, thought process, policy & compliance with legacy system. Security should not be strict to slow down the process or restrict required access, at the same time security should never be compromised. It is a combination of multiple thought process it start with common sense approach, comply with best practices and empowered from most secured algorithm.