The Authorization Code Flow for OAuth 2.0 is targeted at web applications that have a server-side component, which allows the client secret for the authorization server to be kept secret (confidential client). Typically, authorization servers will require a secret to be used when making authentication requests if more sensitive data is wanted, such as personal data or refresh tokens. Without it, you would be restricted to following the Implicit flow for OAuth 2.0, which only returns an access token from the authorization server.
\nIn the Authorization Code flow, the server-side component of the web application can freely manage the user's session upon authenticating with the authorization server without revealing anything about the authorization server's response (such as personal data or refresh token) to the end-user.
\nWhenever we talk about asynchronous programming in JavaScript, there is sometimes confusion in how it can be asynchronous if it is single-threaded. To answer this correctly, I think it's a good thing first to understand the difference between concurrency and parallelism, two terms that are commonly brought up with multithreading. Concurrency describes independent parts of a program to run in an arbitrary order without affecting the outcome. A concurrent application can execute multiple tasks over an overlapping period. This means that while we can start new tasks before the previous one is complete, we cannot perform work on each task simultaneously. You can think of a concurrent execution model as a single chef preparing a meal. Any chef worth their salt can work on multiple dishes (or various parts of a dish) at once. They might chop the vegetables for their stir-fry while the rice is steamed in the rice cooker or leave the vegetables to fry in the pan while cleaning up their workspace. In this scenario, the chef can perform multiple tasks at once; however, at any given time, he is only able to work on a particular unit of work at a given time. You might point out that the chef can perform other actions in this example scenario while something like the rice is steaming, which is technically work still being done. However, the concurrency in this scenario only applies to the chef's context, who is not actively working on the rice as it is being steamed. Similarly, the JavaScript Event Loop allows your scripts (the chef) to hand off tasks like HTTP requests and timeouts to the browser Web API (rice cooker), allowing the script to execute other code portions while waiting for a response. Once the Web API task is complete, it is pushed back into the Event Loop call stack. While the Web API acts as a separate thread where it can complete certain tasks outside the main thread's scope, your actual JavaScript code is still executed on a single thread concurrently. Parallelism describes the ability for independent parts of a program to be physically executed at the same time. A parallel application can distribute its tasks to independent processors (such as different cores or threads of a CPU) to be executed simultaneously. You can think of a parallel execution model as multiple chefs individually each preparing a meal. These individual chefs may be preparing their dishes in a concurrent manner (like the above) or a sequential one; either way, the result is that rather than producing a single meal, the kitchen has prepared multiple meals over a unit of time. Modern browsers allow you to program parallelly by using Web Workers. These spawn separate threads to execute JavaScript independently from the main thread. So we've established that multiple chefs can get a kitchen to produce multiple dishes in the same amount of time as a single dish from a kitchen with a single chef. Modern hardware almost always has multiple threads, so why isn't all code run in parallel? If it takes one chef 10 minutes to prepare one stir-fry and five chefs 10 minutes to prepare five stir-fries, can five chefs produce one stir-fry in 2 minutes? This is where parallel computation can get difficult. Tasks can speed up by distributing the workload onto multiple threads. However, this requires splitting up the workload in a way that can work independently and effectively. Think of how five chefs would prepare a single stir fry together: Similarly, on the computing side, parallel programming solutions are generally harder to implement and debug. Depending on the task, they can sometimes even perform worse than serially run counterparts due to the various costs of overhead (transferring data between threads, creating and destroying threads, synchronization of work, etc.). To conclude this post, neither are inherently superior to the other. Both execution models are useful tools for producing efficient and reliable solutions and are used together in many cases. I hope this helps to clear up the differences between the two, or if not, at least provided a mildly entertaining analogy to illustrate each. As we all know, JSON Web Tokens are a way of sending information between parties in a way where the sender's authenticity can be verified. It is essentially a JSON object with a signature. Using this signature, services that issue these tokens can verify that they are the ones who issued this token and thus can trust the claims which are contained within. The trustworthiness of these tokens make them popular for use in authorization and authentication scenarios: For this post, we'll be focusing on the former use case. So having a token with trustworthy claims is great; we can take the token at its word, and trust all of the information that it has contained within as gospel. Our server is unburdened from having to potentially make database calls to verify the user's role, their permissions, their existence, or even if they're logged in. Once the server has generated the token, as far as it is concerned, no state has to be maintained regarding the validity of the token. It will expire once its expiration time included in its claim has passed. But before we go ahead and use this for all of our authorization needs, we have to remember that while JSON Web Tokens themselves are stateless, to have a robust, feasible, and controllable authorization workflow, we'll have to maintain some state one way or another. You can think of an authorization token as an elementary school hall pass. The teacher (resource server) knows that it is a legitimate hall pass because it is green, 6 cm x 12 cm and has a signature from another member of the faculty. Now imagine that you've issued a hall pass, but now you need to take it back (you've changed your mind, or the kid did something bad). Your options are: Other than the 3rd option which may or may not be feasible depending on your use case (most likely not), we can see that it is not possible to reliably remove or revoke a token without maintaining state. The solutions that I've looked upon Stack Overflow for invalidating these tokens boil down to relying on some form of state, one way or another. Don't get me wrong however, this is not a bad thing in my opinion. Using JSON Web Tokens can and do allow us to minimize the state that we do have to maintain, with minimal added complexity. So let's look at some ways that we can couple state and JSON Web Tokens that allow us to invalidate these tokens effectively. We can maintain a database table containing all of the tokens issued by our server that we would like to accept as valid. This would be a 1:1 session store, with every transaction occurring requiring this table to be checked to prevent an invalidated token from being accepted. While we would not be able to reduce the amount of state being maintained on our server, JSON Web Tokens still provide us with the utility of its trusted claims (and the performance benefits of not needing to check those). We can maintain a database table containing all of the tokens issued by our server that we do NOT want to accept as valid. Every transaction that occurs will require this table to be checked, to prevent an invalidated token from being accepted. Each record would only have to be maintained until the token itself expires. I can't think of any use case where a table of invalidated tokens would regularly be larger than a table of active tokens, so I'd imagine that the table maintained would almost always be smaller than maintaining a table of active tokens. This solution still needs a database lookup, but interestingly requires no state. For this, we can use the hash of a piece of data to sign the token itself. For example, by using the hash of a user's password, when the user changes their password, subsequent transactions involving an old token will fail, as the signature will fail to be verified. The effectiveness of this, however, would depend on your requirements, as this would be limited to invalidating tokens based on changing data (such as changing roles, passwords, etc.). It would not allow you to invalidate a token whenever you want. I think that JSON Web Tokens coupled with a token blacklist is a fantastic way to manage authorization in web applications. This allows you to leverage the benefits of these tokens in reducing the network calls needed to secure your application, reduce the amount of data you need to store to manage sessions, and do so in a reliable way without introducing too much complexity. In JavaScript, web workers allow developers to benefit from parallel programming. Parallel programming enables various computations to be performed at the same time by applications. Web Workers are a browser feature that allows scripts to be executed on a separate thread from the main execution thread of your web application. This allows the main thread of your web application to run without being blocked by slow scripts in your application. Well, sort of. This has been something that had confused me many a time when I was initially learning about JavaScript. JavaScript a synchronous, single-threaded language. However, JavaScript has features that allow you to execute asynchronous code, which is handled by browser engines (on your client) or by your OS (in NodeJS), which are capable of executing code in multiple threads. We work with asynchronous methods in JavaScript by either using callbacks, Promises or async/await. We'll use Promises as an example for exploring asynchronicity in JavaScript. Promises are proxies for values that are not yet available when the Promise is created. This lets you organize parts of your code to run when the value becomes available or if something goes wrong. This does not mean that your code is running asynchronously. As I mentioned before, JavaScript code is executed on a single thread. The callback that processes the response from your created Promises still runs on your single main thread. Promises do, however, allow you to spawn asynchronous tasks, such as file I/O or making an HTTP request which runs outside of your code. This allows your main thread to work on something else while waiting for these tasks to return a response. This means that the callback functions which run after a response is received are called asynchronously. I feel that the distinction between your code running asynchronously vs. being called asynchronously is important, as you will see that you are not able to perform computationally expensive tasks without blocking your main thread, even when using Promises. Here is an example of using an expensive function (finding prime numbers) wrapped in a Promise. You'll find that the above program will print the following: The ordering of What I did find interesting was that the statement printing Web Workers run in a separate thread altogether, with no access to the context of the main thread. Data is sent between the worker and the main thread using a system of messages: the First we need to create the script (we'll just call it The Over in your main script, we'll create a worker object using the constructor Running this script will print the following: You can see that this time, the prime numbers function is actually running on a thread separate from our main one, which allows the main thread to continue printing the statement To reiterate, Web Workers allow you to run your own code on a separate thread, which allows your main thread to continue rendering the UI, receive user input, etc., while your worker thread processes a response. For most web applications, the most expensive operations in your code will often be I/O, interacting with resources in your network. Thanks to JavaScript's Event Loop, these are already offloaded from your main thread to your system's operating system. As such, there is no need for Web Workers when making these kinds of operations. If you need to process large sets of data, there is a decent chance that you will be able to perform this on your server-side before sending it to your front end client for display to the user. This will allow you to rely on JavaScript's event loop to prevent these expensive operations from blocking your main thread. However, if your scenario must have these long-running tasks running on your client end, Web Workers would be an ideal solution for your needs. Some examples of these could be: As Web Workers work on a separate thread, it has no access to the parent page, which calls it. This means that the worker itself cannot manipulate the DOM nor access any data stored within it. It is not able to access the browser's localStorage and sessionStorage either. You are limited to the data sent directly via As with anything multithreaded, adding Web Workers into your application will add complexity to your application. Natively, If your worker can be triggered multiple times, each request will simply be queued and will run when the previous has been completed. For more complex queuing mechanisms, you would have to define this yourself. With discussions dating back a decade, Web Workers are not a new feature. Despite their powerful potential, they haven't been widely adopted. Client side applications, for the most part, just haven't needed to perform intensive tasks where Web Workers would have been a solution. In addition, with a lack of widespread use, finding relatable examples to reference when implementing them is an extra barrier for adoption. Redux Saga is a middleware library used to allow a Redux store to interact with resources outside of itself asynchronously. This includes making HTTP requests to external services, accessing browser storage, and executing I/O operations. These operations are also known as side effects. Redux Saga helps to organize these side effects in a way that is easier to manage. A redux store natively only knows how to dispatch actions and update its state using its root reducer. Actions represent an event describing something happening in your application and an intention to change your application's state. A reducer accumulates values from or stemming from dispatched actions and accumulates these values into the newly updated state of your application. Reducers must be written as a pure function, as it is necessary to enable useful features of Redux such as time travel (replaying past actions). Actions are simply objects passed on into the reducer and are naturally deterministic. Thus we have a problem; there isn't any place in your Redux application to put your side effects in. A Redux middleware lies between an action and a reducer. This enables actions to contain something else other than a plain object, as long as the middleware intercepts this, performs its logic, and returns a plain object to pass along to the reducer. Redux Thunk, a common alternative to Redux Saga, allows functions to be passed into the Redux store dispatch, which checks to see if it is a function or an action object, executing the function in the former case, and directly passing along the action object to the reducer in the latter case. These functions can then perform whatever complex asynchronous logic that it wants and produce a plain action object to be then passed into the reducer. Redux Sagas are slightly different in that a separate set of actions are defined in your Redux application, which is captured exclusively by watcher functions (as part of your saga). Upon capturing the action, the saga will execute the corresponding logic and dispatch a resultant action to your application's reducer. The saga essentially acts as a separate thread to your application, listening for specific actions from your main application to perform complex asynchronous tasks and updating your application's state once it is completed. While I wouldn't say Redux Saga is inherently better than any of the alternatives available, it does have a few benefits that might make you want to consider using it. Redux Saga offers a place completely decoupled from your action creators for you to handle your application's side effects. Some people may feel that this makes your application's data flow harder to follow (which I would agree with), but I think that this decoupling makes organizing your codebase and extending functionality easier down the road. For example, in a situation where you might need to support a workflow that requires multiple HTTP requests to different services in a particular order, Redux Saga allows you to compose granular sagas into a single one and represent this new high-level function with a separate action. Your application can still access each individual HTTP resource in other workflows, but for this particular one, your React component can simply call this high-level action to load whatever it needs from a single place. As far as your component is concerned, your asynchronous logic to load multiple resources in a particular order is abstracted away. Redux Saga also offers us a collection of helper functions that are used to spawn your tasks when some specific actions are dispatched. These can be used to help organize when and how your tasks are executed. For example, one of the most commonly used helper functions is Now imagine that you had two functionally independent components that needed to retrieve the most up to date data from the same place. Previously they existed on two different pages and could both be visited at any time. It would make sense for both components to try to retrieve a fresh copy of the resource whenever it is visited. Now imagine that your specification has changed, and now the two components need to exist on the same page. Now you have a situation where two different components are redundantly spawning the same task. Obviously, you could rewrite one of the components to no longer try to retrieve a fresh copy and rely on the other to create the necessary action to retrieve this resource and populate the application store. Or you could add some logic to ensure that your component does not try to create a new action to retrieve this resource if this resource is already being loaded. But this could also be solved using another Redux Saga helper function: With this, your two independent components can coexist together without changing any component-specific logic! As far as your component is concerned, it asks your saga to retrieve a resource on its behalf and retrieves it from the resultant updated state. Your saga gets to decide how it wants to handle two requests from different components. There is a fair bit more to Redux Saga than I managed to cram into this post. If you're interested in incorporating it into your project or want to know more, check out their fantastic documentation here: Redux-saga. It's packed full of useful examples if you'd like to get into the low-level details. Redux Saga is one of many tools that can help you handle your application's side effects. It's heavy and has a learning curve but contains a lot of functionality that will help keep your codebase neat and modular. When JSON Web Tokens are created, they are typically signed by its issuer. This allows the recipient of the token to validate that the token received contains all of the information encoded by the issuer unmodified and as intended. A signature is not to be mistaken for encryption! The fact that a JSON token is signed does not mean that the data enclosed is unreadable by third parties. All a signature does is ensure that the message is authentic, which it achieves by allowing the recipient to compare the data they’ve received with a trusted claim included in the data (the signature). JWTs are most commonly signed using one of two algorithms: HS256 (HMAC using SHA256), and RS256 (RSA using SHA256). A signature can only be created by someone possessing a secret key, and the original payload. Signatures are generally formed by combining the data to be signed with a secret key, either by appending them together and hashing them (HS256), or by encrypting a representation of that data (a hash) using the secret key (RS256). In both signing algorithms, the data is formatted into an immutable representation in a way that a recipient can check that the creator of the signature was in possession of that particular secret key. HS256 is a symmetric signing method. This means that the same secret key is used to both create and verify the signature. The issuer appends the JWT header and payload with the secret key, and hashes the result using SHA256, creating a signature. The recipient uses their copies of the secret key, JWT header and payload in the same way to reproduce the signature, checking to see if they match. Aside from some incredibly unlikely scenarios, the only way for these signatures to be consistent is if the JWT header, payload and secret shared between the two parties are identical. RS256 is an asymmetric encryption method. This differs from a symmetric scheme in that rather than using a single secret key, a pair of seperate keys are used to encrypt and decrypt the data. The issuer generates a hash of the JWT header and payload using SHA256, and encrypts it using the RSA encryption algorithm, and their private key. The recipient uses their public key to decrypt the signature ciphertext, and then compares it to a hash they’ve reproduced using their copy of the JWT header and payload, checking for consistency. The only way that these resulting hashes are consistent is if the JWT header and payload shared between the two parties are identical, and the public key corresponds to the private key used to encrypt the hash. Both signing schemes are effectively secure, with HS256 being a little faster. However, given this use case, the difference in speed is not particularly relevant. The main consideration on which to use, is in my opinion the symmetric vs asymmetric property of each: Having an unsecured publicly available key is useful in many cases. For example, it can be published openly on the internet as part of a metadata endpoint, allowing JWT configurators to automatically retrieve the key, making for a straightforward and automatic JWT setup. As such, RS256 may be more suitable for situations where data is exchanged between two independent parties. Having a shared secret key can however also be useful in some cases. For example, if the issuer and recipient were both managed by a single party, the two applications would be able to share configurations without having to manage two separate keys. As such, HS256 may be more suitable for situations where data is exchanged within a single partyConcurrency
\nParallelism
\nConcurrency or Parallelism which one is better?
\n\n
\nConclusion
\n\n
\n\n
\nToken Whitelist
\nToken Blacklist
\nUsing a Dynamic Secret to Sign
\nConcluding Remarks
\nIsn't JavaScript already asynchronous?
\n
\nfunction findPrimeNumbers(max) {\n return new Promise((resolve) => {\n console.log("starting findPrimeNumbers");\n let primes = [];\n for (let i = 0; i < max; i++) {\n if (i === 0 || i === 1) {\n continue;\n }\n let isPrime = true;\n for (let y = 2; y < i; ++y) {\n if (i % y === 0) {\n isPrime = false;\n break;\n }\n }\n if (isPrime) {\n primes.push(i);\n }\n }\n console.log("prime numbers found");\n resolve(primes);\n });\n}\n\nconsole.log("a");\nfindPrimeNumbers(100000).then(() => {\n console.log("b");\n});\nconsole.log("c");
\na\nstarting findPrimeNumbers\nprime numbers found\nc\nba, b, and c is not particularly noteworthy, as we already know that the callback for the findPrimeNumbers function will only execute after the main thread has nothing left to do, after printing c.c waits until the findPrimeNumbers function completes before being executed. To prevent functions like this from blocking the main thread, we'll have to use Web Workers.postMessage() method is used to send a message from one to the other, and the onmessage event handler is used to receive and respond to messages.find-prime-numbers.js) that the Web Worker will run:
\nonmessage = (event) => {\n const { data } = event;\n const primes = findPrimeNumbers(parseInt(data));\n postMessage(primes);\n};\n\nfunction findPrimeNumbers(max) {\n console.log("starting findPrimeNumbers");\n let primes = [];\n for (let i = 0; i < max; i++) {\n if (i === 0 || i === 1) {\n continue;\n }\n let isPrime = true;\n for (let y = 2; y < i; ++y) {\n if (i % y === 0) {\n isPrime = false;\n break;\n }\n }\n if (isPrime) {\n primes.push(i);\n }\n }\n console.log("prime numbers found");\n return primes;\n} onmessage handler receives an event with the message itself contained in the event's data attribute. Here we execute the findPrimeNumbers() function again, and use postMessage() function to send the result back to the main thread.new Worker(), which runs the named JavaScript file containing the code that we just wrote, which will run in the worker thread.
\nconst primeNumberWorker = new Worker("./find-prime-numbers.js");\nprimeNumberWorker.onmessage = (event) => {\n console.log("b");\n};\n\nconsole.log("a");\nprimeNumberWorker.postMessage("100000");\nconsole.log("c");
\na\nc\nstarting findPrimeNumbers\nprime numbers found\nbc while the worker thread works out its own response.When should you use JavaScript Web Worker
\n\n
\nJavascripty Web Worker Limitations
\npostMessage or IndexedDB for accessing stored client data.postMessage is the only direct line of communication between threads. You will need to define how more complex workflows will be managed between your main thread and worker thread (such as error handling).Conclusion
\nA High-Level Introduction to Redux Saga
\nWhy do we even need this?
\nThe solution
\nRedux Saga vs. alternatives
\ntakeEvery(). This instructs the middleware to spawn a new task for every action dispatched to your store matching a given pattern. This provides a behaviour similar to Redux Thunk and is as simple as it gets: \"Application tells you to fetch something, go fetch it\".take(). This function instructs the middleware to spawn a new task for an action dispatched matching a given pattern but will effectively ignore any new actions until the spawned task has been completed.Concluding thoughts
\nJWT Signing Algorithms
\nHow does a signature ensure authenticity?
\nHS256
\nRS256
\nWhen to use which?
\n\n
\n