In this blogpost, we will look at API Security. More specifically, we will see how we can use Oauth for RESTful APIs. For this we will be using some already available opensource software.
The code for the example in this post is available at : https://github.com/ihsanizwer/API-Security-Oauth-for-RESTful-API. Basically, what I am trying to do here is explain the functionality of the resource server. So therefore, firstly we need to have an idea about what resource server is. For this example I have written my own Authorization server.
Resource Server’s functionality
When an access token is presented, if the token is valid, then resource server must enable client to obtain resources. Here we validate the access token by talking to the OAuth token introspection endpoint. In other cases, when Json Web Token(JWT) is in the picture, we can simply validate within the resource server. Because resource server has the public key of the Authorization server and therefore can validate. In this example on API security, that is not the case.
API security – Lets run the code!
These are the steps you need to follow to get this application on API secuirty to work.
1. Clone the git repo using
git clone https://github.com/ihsanizwer/API-Security-Oauth-for-RESTful-API.git
2. Copy the .war file to the webapps directory of your tomcat server. This is because we will be using port 8080 and another port for our resource server. The Authorization Server is a servlet and will be accessible from port 8080
3. Start up tomcat server. sh catalina.sh start
4. Start the resource server by going in to the git repo that you cloned and typing,
mvn spring-boot:run -Drun.jvmArguments='-Dserver.port=8084'. Here our resource server is running in port 8084.
5. Send requests to the API using the curl command in linux. You can send multiple requests to observe the behavior.
curl -XPOST -H 'Authorization: Bearer dafebe06c5c3ca986001aaa22bf1404253134440fd53bed99f2f58d1853a995fca9d7c9b999c3232' 'http://localhost:8084/api/user'
6. Observe outcomes and comprehend behaviour.
If the token that was sent was a valid access token, then the response from the Resource server will be 200 OK. If it is an invalid request, then the response will be 400 BAD REQUEST.
API security – Internal functionality.
Now that we have a good idea on how this works from the outside, let’s dive in under the hood. The flow that takes place internally goes like this:
1. The API is being called with access token set on the header. This is a POST request.
2. The API (Resource Server) talks to the Token Introspection Endpoint of the Authorization Server.
3. Authorization Server validates the token. It creates a JSON object containing whether the access token is valid or not. Then it sends it back to the Resource Server.
4. If the active field of the JSON is set to true, Resource server sends 200 OK to client. Otherwise it sends 400 BAD REQUEST to the client.
API Security – Use case
This kind of setting can be used if we need to authenticate the clients invoking the API endpoints. Especially if those endpoints give out protected information or protected resources.