Basic understanding of OAuth2.0

OAuth2.0 allows third-party applications to grant limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf. Access is requested by a client, it can be a website or a mobile application for example.

Roles

OAuth2.0 defines 4 roles :

• Resource Owner: generally yourself.
• Resource Server: server hosting protected data (for example Google hosting your profile and personal information).
• Client: application requesting access to a resource server (it can be your PHP website, a Javascript application or a mobile application).
• Authorization Server: server issuing access token to the client. This token will be used for the client to request the resource server. This server can be the same as the authorization server (same physical server and same application), and it is often the case.

Tokens

Tokens are random strings generated by the authorization server and are issued when the client requests them.

There are 2 types of token:

• Access Token: this is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorization server.
• Refresh Token: this token is issued with the access token but unlike the latter, it is not sent in each request from the client to the resource server. It merely serves to be sent to the authorization server for renewing the access token when it has expired.

Let’s understand the concept now.

1. There are data of a user.

2. There is a server which manages the user’s data. The server is called “Resource Server”.

3. There is a “Client Application” which wants to use the user’s data.

4. Let’s prepare a gate to pass the user’s data through. The gate is called “API”.

5. The client application requests the user’s data.

6. The resource server returns the user’s data.

7. What if there is a malicious client application?

8. Even if the client application that requests the user’s data is a malicious one, …

9.  the resource server returns the user’s data.

10. Even a malicious application can get the user’s data.

11. We need a mechanism to protect the user’s data.

12. In the best practice, an “Access Token” is given to the client application in advance. An access token represents that the said client application has been given permissions to access the user’s data.

13. The client application presents the access token when it requests the user’s data.

14. The resource server extracts the access token that is included in the request, …

15. … and confirms that the access token denotes that the client application has permissions to access the user’s data.

16. After the confirmation, the resource server returns the user’s data.

17. To make this mechanism work, an access token must be given to the client application in advance.

18. Consequently, we need someone who issues access tokens.

19. Someone who issues access tokens …

20. … is called “Authorization Server”.

21. The relationship between a client application and an authorization server is as follows.

22. An authorization server generates an access token …

23. … and issues the access token to a client application.

24. Let’s review what we’ve learned so far. Characters are an “Authorization Server”, a “Client Application” and a “Resource Server”.

25. The authorization server generates an access token …

26. … and issues the access token to the client application.

27. The client application requests the user’s data with the access token.

28. The resource server extracts the access token from the request, …

29. … confirms that the access token has permissions to access the user’s data …

30. … and returns the user’s data to the client application.

31. In the flow above, the first step is access token generation by an authorization server. However, in a real flow, the user is asked before an access token is issued.

32. First, the client application requests an access token.

33. Then, the authorization server asks the user whether to grant the requested permissions to the client application.

34. If the user allows the authorization server to issue an access token to the client application, …

35. … the authorization server generates an access token …

36. … and issues the access token to the client application.

37. By the way, pay attention to the part encircled by the yellow ellipse.

38. The part represents an access token request and a response to the request.

39. And, it is “OAuth 2.0” that has standardized the part. Details of OAuth 2.0 are described in the technical document, RFC 6749 (The OAuth 2.0 Authorization Framework).

Some notes on Thread Pool in Java

A thread pool reuses previously created threads to execute current tasks and offer a solution to the problem of thread cycle overhead and resource thrashing. Since the thread is already existing when the request arrives, the delay introduced by thread creation is eliminated, making the application more responsive.

• Java provides the Executor framework which is centered around the Executor interface, its sub-interface – ExecutorService and the class – ThreadPoolExecutor, which implements both of these interfaces. By using the executor, one only has to implement the Runnable objects and send them to the executor to execute.
• To use thread pools, we first create an object of ExecutorService and pass a set of tasks to it. ThreadPoolExecutor class allows to set the core and maximum pool size. The runnable that are run by a particular thread are executed sequentially.

Executor Thread Pool Methods:-

• newFixedThreadPool(int) :- Creates a fixed size thread pool.
• newCachedThreadPool() :- Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available.
• newSingleThreadExecutor() :- Creates a single thread.

Risks in using Thread Pool:-

1. Deadlock:- While deadlock can occur in any multi-threaded program, thread pools introduce another case of deadlock, one in which all the executing threads are waiting for the results from the blocked threads waiting in the queue due to the unavailability of threads for execution.
2. Thread Leakage:- Thread leakage can occur if a thread is removed from the pool to execute a task but never return to the pool when task is completed. As an example, if the thread throws an exception and pool class does not catch an exception, then the thread will simply exit, reducing the size of the thread pool by one. If this repeats many times, then pool would eventually become empty and no threads would be available to execute other requests.
3. Resource sharing:- If the thread pool size is very large then time is wasted in context switching between threads. Having more threads than the optimal number may cause starvation problem leading to resource thrashing as explained.

Important Points:-

1. Don’t queue tasks that concurrently wait for results from other tasks. This can lead to the situation of deadlock as described above.
2. Be careful while using thread for long lived operation. It might result in the thread waiting forever and would eventually lead to resource leakage.
3. The thread pool has to be ended explicitly at the end. If this is not done, then the program goes on executing and never ends. Call shutdown() on the pool to end the executor. If you try to send another task to the executor after shutdown(), it will throw a RejectedExecutionException.
4. One needs to understand the tasks to effectively tune the thread pool. If the tasks are very contrasting then it make sense to use different thread pools for different type of tasks so as to tune them properly.