DEV Community: Phil the Dev

Understanding JWTs: A Simple Guide for Beginners

Phil the Dev — Wed, 05 Jul 2023 15:40:59 +0000

What is a JWT?

JWT, short for JSON Web Tokens, is a compact, URL-safe way of representing claims (information) to be transferred between two parties, the client and server. Think of it like a secret message in the form of a cryptographically signed note, which can only be understood by the intended recipient.

Structure of a JWT

A JWT has three distinct parts, each separated by a dot (.):

Header: It contains metadata about the token and the cryptographic algorithm used, usually HMAC SHA256 or RSA.
Payload: The actual data that the token carries is stored here. It's also known as the 'claims' and can include data like user details and additional metadata.
Signature: The signature is a cryptographically secured proof that verifies the sender and ensures the message wasn't altered during transit.

How Does a JWT Work?

Here's the play-by-play of JWT in action:

A client logs in using their credentials, sending a request to the server.
The server verifies these credentials. If they're valid, the server generates a JWT and sends it back to the client.
The client stores the JWT, usually in local storage, and includes it in every subsequent HTTP request's header.
The server, upon receiving these requests, verifies the JWT. If it's valid, the client is authenticated and authorized.

Why Use JWT?

JWTs are universal - any programming language can generate a JWT because they're essentially JSON. Also, they facilitate maintaining session state on the client, reducing server load, which is more scalable.

Security Considerations

While JWTs are handy, they do come with some vulnerabilities:

Token Theft: JWTs are stored on the client-side, and hence can be stolen. Always ensure your transmission is secure, preferably via HTTPS.
No In-built Invalidity Mechanism: JWTs can't be invalidated individually or in a group from a user, due to their stateless nature.
Token Size: Storing too much data in a JWT can make it heavy, affecting network performance.
Algorithm Vulnerabilities: Some algorithms in the JWT header are vulnerable to attacks. Always use secure and updated algorithms, and treat your signing keys like secrets.

In conclusion, JWTs are a potent tool in web development, providing stateless, secure, and scalable communication. Remember, how effectively you wield JWTs in your application depends on your specific needs and the level of security you require.

I hope this gives you a better understanding of JWTs! Feel free to share your thoughts 😄

Understand OAuth in 3 minutes

Phil the Dev — Mon, 03 Jul 2023 15:40:45 +0000

The term OAuth is likely a term on every developer's mind. But how do you break down this concept to someone just starting their coding journey, or even to someone who isn't involved in development at all? Here's my attempt to explain it 😄

What is OAuth?

OAuth, which stands for Open Authorization, is a standard protocol that allows third-party applications to access user data without exposing their password. Imagine using your university ID to check out a library book. You're not giving the librarian your login details, just proof that you're a student. The librarian doesn't see your grades or tuition details, just confirms you're allowed to borrow books.

How Does OAuth Work?

Think of when you log into a new app, and it asks if you want to log in using your Google account. Once you click 'yes', you're redirected to a Google sign-in page. Here's where OAuth comes into play.

You input your Google credentials (this is authentication, proving who you are), but instead of giving these credentials back to the original app, Google sends back a token. This token is like a temporary key, giving the app permission to access specific information from your Google account for a set amount of time.

For a visual explanation I've found the following diagram particularly helpful:

Why is OAuth Important?

OAuth plays an essential role in enhancing user experience and security. By using OAuth, users don't have to remember another set of credentials, and the application doesn't have to manage secure storage of user passwords. Plus, users can control which information they want to share and can revoke access at any time.

OAuth in a Nutshell

To put it simply, OAuth is like a digital passport. In the realm of web security, it serves as a safe and efficient way to give applications the ability to communicate with each other using tokens, instead of sharing sensitive information, like passwords.

Remember, OAuth isn't about gaining access but about giving limited access to third-party services without exposing user credentials. It's like giving the keys to your car but not your house!

Summing Up

Grasping the concept of OAuth is crucial in the modern landscape of web development and security. It's all about protecting user data while providing the flexibility of interconnected services. By understanding and implementing OAuth, we can offer a secure and streamlined user experience.

As with any security strategy, the way you implement OAuth will depend on your specific application's needs and the level of security it requires.

As always you are welcome to share your thoughts 😄

SOLID Principles: A Quick Guide (.NET examples)

Phil the Dev — Wed, 28 Jun 2023 18:35:53 +0000

Recently, I was thinking about some topics for a short and knowledge-refreshing article. One subject that I rarely hear being talked about, but is really important in software development, are the SOLID principles. For a lot of experienced developers, these "rules" may seem pretty clear, yet I often come across code changes that don't follow these principles. Sometimes, I even find some that I've made myself, so no disrespect intended.

To enhance the value of this article, I've included some basic explanations and examples in C#

Single Responsibility Principle (SRP)

Each class should have one, and only one, reason to change. This means a class should only have one job.

Example:

public class Order
{
    public void CalculateTotalSum() { /*...*/ }
    public void GetItems() { /*...*/ }
    public void PrintOrder() { /*...*/ }
    public void ShowOrder() { /*...*/ }
}

This Order class violates SRP because it has more than one responsibility. A better approach is to split this into several classes, each handling a single concern.

Open-Closed Principle (OCP)

Software entities should be open for extension but closed for modification. This encourages stability while allowing system growth.

Example:

public class Rectangle
{
    public double Height { get; set; }
    public double Width { get; set; }
}
public class AreaCalculator
{
    public double TotalArea(Rectangle[] arrRectangles)
    {
        double area = 0;
        foreach (var objRectangle in arrRectangles)
        {
            area += objRectangle.Height * objRectangle.Width;
        }
        return area;
    }
}

In this example, if we want to add a new shape, we'd have to modify the AreaCalculator class, which violates OCP.

Liskov Substitution Principle (LSP)

This principle insists that subclasses must be substitutable for their base classes without affecting functionality.

Example:

public class Vehicle
{
    public virtual void StartEngine() { /*...*/ }
}

public class ElectricCar : Vehicle
{
    public override void StartEngine() { /*...*/ }
}

public class Bicycle : Vehicle
{
    public override void StartEngine() { /*...*/ }
}

Here, a Bicycle doesn't have an engine to start, so substituting a Vehicle with a Bicycle would cause issues, thus violating LSP. A better approach would be to have a separate class for vehicles with engines.

Interface Segregation Principle (ISP)

No client should be forced to depend on interfaces they do not use.

Example

public interface IWorker
{
    void Work();
    void Eat();
}

Here, if a robot implements IWorker, the Eat method is useless. This violates ISP. It's better to break this into two interfaces: IWorker and IEater.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules, but both should depend on abstractions. This reduces tight coupling.

Example:

public class Email
{
    public void SendEmail() { /*...*/ }
}
public class Notification
{
    private Email _email;
    public Notification()
    {
        _email = new Email();
    }
}

here, the Notification class is tightly coupled with the Email class. Using DIP, we can introduce an interface to decouple them.

Despite their importance in writing maintainable and scalable code, these principles are frequently overlooked. For me it was a short, simple and much needed refresher. Hopefully for any other reader too 😀
Feel free to comment your thoughts

Happy coding!

The Art of Code Commenting

Phil the Dev — Sun, 25 Jun 2023 18:21:12 +0000

Lately, I've been reflecting a lot on my process of documenting and teaching my code to others. As a young dev 😅, I'm always looking for ways to improve. One thing I've noticed in my past work is that the code commentary often wasn't optimal. Let me tell you, returning to a project that I haven't touched for almost two years and finding only 10 comments across the entire project is hellish. So, I hope you can learn something from this article and my thoughts.

Also, make sure to keep an eye out for my upcoming article specifically focusing on the art of code commenting in .NET. You won't want to miss it! Be sure to follow me to stay up-to-date with all my latest insights and articles.

Comments in code are akin to leaving notes to your future self and to others who might work on the code. Why did I write this piece of code in a certain way? Why did I not choose an alternate approach? Code, by its nature, tells you "how", comments should ideally tell you "why". This is a philosophy I've come to appreciate over the years.

So based on my reflection and my past experience I think the following practices are making a lot of sense. At least to me 😅

Comment the Why, not the What: I strive to write code that is self-explanatory in terms of what it does. My comments are then dedicated to providing context, explaining my decisions, or highlighting any non-obvious aspect of the code.
Keep Comments Relevant: One of the things I've learned the hard way is that outdated or incorrect comments can be worse than no comments. So, every time I update my code, I make it a point to update relevant comments as well.
Avoid Redundant Comments: As tempting as it might be to comment everything, I avoid commenting on the obvious. I believe that if my code is clean and clear, it should largely speak for itself.
Use XML Documentation Comments: I find XML documentation comments an excellent tool to provide information about my code's classes, methods, properties, etc. Not only do they help generate a separate XML file, but they also provide IntelliSense documentation in the Visual Studio code editor, making life easier for me and my team.
Commented-Out Code: Early on, I used to leave commented-out code in my source files, but soon I realized that it creates unnecessary clutter. I've come to rely on source control for remembering old code instead.

In the end, I would say that code commenting is truly an art form. When done right, it can greatly enhance the understandability of your codebase and improve productivity for both yourself and others. And always remember, your comments are a reflection of your thought process, so strive to make them as clear as possible.

I'm sure there are many more insights to be gathered from the vast community of developers out there. So, I encourage you all to share your thoughts and practices you've used over the years in the comments section. Let's learn from each other!

Enjoy coding 😄

Beyond 200, 404, and 500: Exploring Lesser-Known HTTP Status Codes

Phil the Dev — Fri, 23 Jun 2023 17:15:46 +0000

Recently, while troubleshooting an issue with a third-party API, I came across an HTTP status code that I hadn't seen in a while. Beyond the commonly seen 200 (OK), 404 (Not Found), or 500 (Internal Server Error), this was one of the lesser-known ones and it got me interested. So, I decided to look into other articles about uncommon status codes. In this article, I'd like to share some of these that I haven't used a lot myself.

202 (Accepted): Indicates that a request has been received and understood but is not immediately acted upon, typically useful for asynchronous tasks.
204 (No Content): Often used in DELETE operations, this status code denotes a successful request that doesn't require a further response.
205 (Reset Content): Instructs the client to reset its document view, potentially useful when resetting a user interface.
206 (Partial Content): If only part of the resource is sent, following a range header from the client, this status code is employed, typically useful for handling large files.
207 (Multi-Status): This is leveraged to provide multiple independent responses for a single request, primarily utilized in Web Distributed Authoring and Versioning (WebDAV).
226 (IM Used): This status code indicates that the server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. It's useful when the client has applied a series of range requests, with the 226 status code indicating that the entire set has been fulfilled.
301 (Moved Permanently): Announces that a resource's URL has permanently changed, proving essential during URL restructuring or website migration.
304 (Not Modified): A boon for efficient caching, this status code informs the client that the cached version of the response is still valid.
307 (Temporary Redirect): Indicates a temporary relocation of the resource, suggesting clients to continue using the original URL for future requests.
409 (Conflict): Signifies a conflict in request parameters, such as simultaneous updates on a single resource from different clients.
418 (I'm a teapot): While a humorous Easter egg from 1998, it's used by some APIs for rate limiting.
422 (Unprocessable Entity): Indicates that the server can't process the request, despite understanding its syntax, commonly encountered in RESTful APIs and WebDAV.
429 (Too Many Requests): This status code is used to implement rate limiting, thereby preventing potential server overload.
451 (Unavailable For Legal Reasons): Servers resort to this status code to deny access to resources due to legal demands.

These are just a few of the numerous status codes defined in HTTP. However, not all of them make their way into everyday use, while others remain hidden in specific scenarios or API documentation. If you've come across an unusual status code in your development journey or have a particular one that you find intriguing, I would love to hear about it. Please share your experiences in the comments.

Authentication vs. Authorization

Phil the Dev — Tue, 20 Jun 2023 19:06:41 +0000

When building web applications, there are two key security terms you need to know - Authentication and Authorization. They may seem similar, but they have different roles in ensuring the security of an application. Let's simplify these concepts a bit.

Authentication

Authentication is all about proving who you are to the system. It is the process of validating a user's identity. It could be a user, a login, or a session. The system checks if the person is genuinely who they claim to be. This is often done using a username and password, but it could also involve more advanced methods like biometric scans or two-factor authentication.

Imagine logging into a website. You enter your username and password, and the website checks if they match what it has on record. If it's a match, you're authenticated. You've successfully proved your identity to the system.

Authorization

After the system knows who you are (thanks to authentication), it needs to know what you can do within it. This is where authorization comes into play. Authorization is all about permissions - it determines what actions you can take or what resources you can access in the system.

Think about using a computer where you're not the admin. You can do some things (like creating a document), but not others (like installing new software). That's an example of authorization at work.

The Core Difference

In simple terms, authentication is about proving who you are, while authorization is about what you can do in the system.

Think about it this way: Authentication is like unlocking and entering your house with a key. Authorization is like knowing which rooms you're allowed to go into once you're inside.

Summary

Both authentication and authorization are important for web security. If a system doesn't manage these well, it's like leaving your front door wide open - not a good idea!

How you use these processes depends on your application's needs, the tools you're using, and how secure you want it to be. You could use something like JSON Web Tokens (JWT) to manage both processes, or OAuth if you want to let third parties have access without exposing user credentials.

In summary, knowing the difference between authentication and authorization is important for building secure web applications. They're two different concepts, but both are key parts of web security.