In the internet ecosystem of increasingly intertwined applications, when one application wants to perform some action on another application on the behalf of a user, a need arises of how to do this without sharing the password of one application to another. A common example of this is sign-in with Facebook by apps that want to post something on your timeline or want to access your Google Drive. If you share your Facebook password with such apps for them to be able to access your timeline and a data breach happens with those apps, your Facebook credentials also come under threat. Also, by sharing your password you are giving such apps full control of your Facebook account instead of limited access. To solve this challenge, a protocol, called OAuth, was defined.
OAuth is an open-standard authorization protocol/framework that enables applications to gain limited access to user accounts of another application without sharing a password. These applications are provided with an authorization token which can be used for using services of another application on your behalf without compromising your password. OAuth can be used to authorize applications, APIs, devices, and servers.
On a high-level, it is a secured delegated process of authorization and limited access over HTTP rather than using your credentials that minimizes the security risk. If any security breach happens and your data is stolen from the app that has access to your Facebook, your Facebook password is safe. No worries.
OAuth has two versions – OAuth 1.0a and OAuth 2.0. Both versions completely differ from each other in terms of specifications and not compatible to be used together. But OAuth 2.0 version is used most widely and we’ll focus on this one only while referring to OAuth unless mentioned explicitly.
Actors and Flow
There are four actors, also referred to as roles, in an OAuth flow.
- Resource Owner (User) – the owner of the respective data that resides on the resource server. The resource owner authorizes the account access which is limited to the scope of granted authorization.
- Resource Server (API) – It is where the user account/resources are hosted in a protected environment.
- Client (Application) – the application that requests access to the user account.
- Authorization Server (API) – Authorization server performs the identity verification in order to issue the access token.
These actors interact with each other based on the OAuth protocol. Please note that the OAuth protocol is about authorization, not authentication. The general flow of an OAuth protocol is as follows:
- The client wants to access the resource server and asks for permission from the user.
- The user either authorizes the request or deny it.
- In the event of authorization, the client gets an authorization grant.
- The client, then, presents this authorization grant and his identity to the authorization server and requests for an access token.
- If the client has both, a valid identity and an authorization grant, the authorization server provides it with an access token.
- The client, then, goes to the resource server and requests the resource access by presenting the access token to it.
- The resource server provides the permitted limited access to the client only if the token is valid.
Challenges in Monitoring OAuth-enabled Applications
OAuth implementation enables your app to get access to server resources on other apps with privacy protection and great user experience. But at the same time, OAuth poses some challenges in monitoring your application. Let’s take a look at those challenges.
Token management – OAuth implementation requires the management of tokens with state management. That means these tokens are refreshed and rotated. If an authorization error occurs, it becomes difficult to figure out which actor in the OAuth protocol is at fault. It becomes a debugging nightmare.
OAuth request/response dependency – What if your OAuth provider changed something in their mechanism? Even the slightest change in request/response params can break your entire application. It may take a while before you figure it out if your developers are not paying attention to new releases by your OAuth provider.
Callbacks – Depending upon the implementation, it may take more than one API calls between all actors for a successful OAuth transaction. In most cases, the callbacks method is used to achieve this which can be complex enough to trace if anything breaks in-between. Traditional monitoring tools are not enough for pinpointing callback errors, increasing the debugging time, and hence increasing your downtime.
Configuration – This is important for making the lives of your DevOps team easy. If you are using a monitoring tool that does not specialize in highly configurable HTTP(S) tasks, you will have a hard time monitoring OAuth flows involving token expiry/renewal and multiple API calls over HTTP(s).
The Solution for Monitoring OAuth-enabled Applications
Synthetic monitoring is an excellent choice when we deal with third-party dependencies, HTTP(S), REST APIs, complex user paths, and custom login mechanism like OAuth, etc.
Synthetic monitoring works by simulating end user behaviors with custom scripts, in a highly configurable environment to support architecture flexibility, and then monitoring the traffic and flow in a proactive manner. This helps in detecting and resolving issues before real users face them. The Dotcom-Monitor platform utilizes a point and click scripting tool, called the EveryStep Web Recorder, to create scripts that can simulate user paths, as well as verify content that is returned as a response to specific actions. To overcome the monitoring challenges posed by OAuth implementation, you will need to use specialized synthetic monitoring tools with the following must-have capabilities:
Multi-step web transaction monitoring – As we briefly mentioned, a successful OAuth transaction is a multi-step process between its actors. Synthetic monitoring gives you the ability to configure multi-step monitoring for OAuth transactions and continuously monitor them for availability and performance. Multi-task monitoring will tell you exactly which step is responsible for the broken flow so that you will be able to fix it quickly.
Custom scripts with HTTP/S tasks – Actual OAuth implementation differ from applications to applications depending on the architecture and security policies.
Synthetic Web Services Monitoring tool allows you to write highly configurable HTTP(s) tasks and custom scripts for complex user paths. This will help you monitor the end-to-end flow of the OAuth transaction of your application and overall health of APIs and callbacks. Additionally, if you need to verify data, such as usernames, that are returned as a response, you can set up the scripts with the EveryStep Web Recorder to verify those specific keywords.
In addition to these capabilities, synthetic monitoring tools are a valuable asset to monitor third-party dependencies, web services and protocols (SOAP, REST, TCP, and ICMP protocols ), and infrastructure. Dotcom-Monitor allows you to configure multi-step transaction for OAuth-based web API using HTTP(s) task and continuously check for uptime, performance, and functionality 24/7.