DEV Community: Hem

🔑 OAuth 2.0 flows explained in GIFs

Hem — Tue, 14 Jul 2020 05:46:03 +0000

In this post, we will be covering all OAuth 2.0 flows using GIFs that are simple and easier to understand. This post can be used as a cheat-sheet for future reference as well!

Note: Feel free to ⏩ skip to the flows directly if you are already aware of OAuth.

Hold on, what's OAuth❓

OAuth (Open Authorization) enables third-party websites or apps to access user's data without requiring them to share their credentials. It is a set of rules that makes access delegation possible. The user gets to authorize which resources an app can access and limits access accordingly.

Terminologies 🧱

Now that we know what OAuth is about, let us quickly cover the terminologies before we dive-in.

Term	Description
Client 📦	The application that seeks access to resources. Usually the third-party.
Resource Owner 👤	The user who owns the resources. It can also be a machine 🤖 (E.g. Enterprise scenarios).
Resource 🖼	Could be images, data exposed via APIs, and so on.
Resource Server 📚	Server that hosts protected resources. Usually, an API server that serves resources if a proper token is furnished.
Authorization Server 🛡	Server responsible for authorizing the client and issuing access tokens.
User-Agent 🌐	The browser or mobile application through which the resource owner communicates with our authorization server.
Access Token 🔑	A token which is issued as a result of successful authorization. An access token can be obtained for a set of permissions (scopes) and has a pre-determined lifetime after which it expires.
Refresh Token 🔄	A special type of token that can be used to replenish the access token.

Now, let us relate these terminologies in an abstract OAuth flow based on an example (1).

An end-user (resource owner 👤) grants a printing service (app 📦) access to their photo (resource 🖼) hosted in a photo-sharing service (resource server 📚), without sharing their username and password. Instead, they authenticate directly with a server trusted by the photo-sharing service (authorization server 🛡), which issues the printing service delegation-specific credentials (access token 🔑).

Note that our app (client) has to be registered in the authorization server in the first place. A Client ID is returned as a result. A client secret is also optionally generated depending on the scenario. This secret is known only to the authorization server and the application.

Okay, enough theory! It is time for some GIFs to understand the authorization scenarios/flows!

Flows in OAuth 2.0

Authorization Code Grant
Authorization Code Grant with PKCE
- Code Transformation Method (CM) - Meet SHA256
- Code verifier (CV) & Code Challenge (CC)
Client Credentials Grant
Resource Owner Password Credentials Grant
Implicit Grant

1. Authorization Code Grant flow

It is a popular browser-based authorization flow for Web and mobile apps. You can directly relate it with the above-mentioned example. In the diagram below, the flow starts from the Client redirecting the user to the authorization endpoint.

This flow is optimized for confidential clients. Confidential clients are apps that can guarantee the secrecy of client_secret. A part of this flow happens in the front-channel (until the authorization code is obtained). As you can see, the access_token 🔑 exchange step happens confidentially via back-channel (server-to-server communication).

Now you might naturally wonder, 'What about public clients?!'

2. Authorization Code Grant with PKCE

Public clients using authorization code grant flow have security concerns. Be it single-page JS apps or native mobile apps, it is impossible to hide the client_secret as the entire source is accessible (via DevTools or App Decompilation). Also, in native apps where there is a custom URI scheme, there is a possibility of malicious apps intercepting the authorization code via similar redirect URIs.

To tackle this, the Authorization Code Grant flow makes use of Proof Key for Code Exchange (PKCE). This enables the generation of a secret at runtime which can be safely verified by the Authorization Server. So how does this work?

2.1. Transformations - Meet SHA256

Basically the client generates a random string named Code Verifier (CV). A Code transformation method (CM) is applied to the CV to derive a Code Challenge (CC) ✨ As of now, there are two transformation methods plain or S256 (SHA-256)

In plain transformation, CC will be equal to CV. This is not recommended for obvious security reasons & hence S256 is recommended. SHA256 is a hash function. On a high-level, it takes input data and outputs a string. However, there are special characteristics to this output string:

This string is unique to the input data and any change in the input will result in a different output string! One can say, it is a signature of the input data.
The input data cannot be recovered from the string and it is a one-way function (Refer the GIF above).
The output string is of fixed-length.

2.2. How do we generate the Code Challenge (CC) from the Code verifier (CV) ?

You might have already guessed it. Take a look at the diagram to understand how CC is generated from CV. In this case, since SHA256 is used, CV cannot be generated from CC (Remember, it is a one-way transformation). Only CC can be generated from CV (Given that the transformation method is known - S256 in our case).

PKCE flow

Note that the flow starts with CV and CC generated first replacing the client_secret.

Now that we know how CV, CC is generated, let us take a look at the complete flow. Most parts are similar to the authorization code grant flow. The CV and CC are generated even before the flow starts. Initially, only the CC and CM are passed to obtain an authorization code. Once the authorization code is obtained, the CV is sent along to obtain the access token.

In order for the authorization server to confirm the legitimacy, it applies the transformation method (CM, which is SHA256) on the received CV and compares it with the previously-obtained CC. If it matches, a token is provided! Note that even if someone intercepts the authorization code, they will not have the CV. Thanks to the nature of the one-way function, a CV cannot be recovered from CC. Also, CV cannot be found from the source or via decompilation as it is only generated during runtime!

3. Client Credentials Grant flow

In the above flows, a resource owner (user) had to provide consent. There can also be scenarios where a user's authorization is not required every time. Think of machine-to-machine communication (or app-to-app). In this case, the client is confidential by nature and the apps may need to act on behalf of themselves rather than that of the user.

Also, this is the simplest of all flows.

4. Resource Owner Password Credentials Grant flow

This flow is to be used only when there is a high degree of trust between the resource owner and the client. As you can see, initially, the username & password is obtained from the R.O and are used to fetch the access_token. The username & password details will be discarded once the token is obtained.

This flow is not recommended for modern applications and is often only used for legacy or migration purposes. It carries high risk compared to other flows as it follows the password anti-pattern that OAuth wants to avoid in the first place!

5. Implicit Grant flow

This flow is no longer recommended officially! Implicit grant was considered an alternative to Authorization Code Grant for public clients. As you can notice, the public client does not contain the client_secret and there is no back-channel involved. In fact, the access token is obtained immediately after the consent is obtained.

However, the token is passed in the URL fragment (Begins with #) which will never be sent over the network to the redirect URL. Instead, the fragment part is accessed by a script that is loaded in the frontend (as a result of redirection). The access_token will be extracted in this manner and subsequent calls are made to fetch the resources. As you can already see, this flow is susceptible to access token leakage and replay attacks.

It is recommended to use the Authorization Code Grant or any other suitable grant types instead of Implicit.

Hope this post was useful. Checkout RFC 6749, RFC 7636 to dig deeper into the steps involved in each of the flows.

Feel free to share your thoughts as well. Don't forget to share this post if you found it useful 🚀

Let me know what you would like to see next as a part of the GIF series! Until then, stay OAuthsome!✨

🐥 Twitter	💼 LinkedIn

👩‍💻👨‍💻Running a Highly Engaging Virtual Developer Event

Hem — Mon, 18 May 2020 06:10:03 +0000

How do you run technical sessions without participants dozing over the monologue of the presenter?
How do you ensure that the participation rate doesn't drop hard like Skrillex beats on the second day of the event?
How do you maintain the liveliness of an in-person event without running into the territory of graveyard silence?

Well, honestly, we didn't know the answers either. All that we knew was that we had some exciting announcements for our developers. We huddled together and worked our way through these questions, leading to our first-ever virtual developer event.

Here are a few things that worked out really well:

1️⃣ Developers love features, but more so when it's feedback-driven:

Freshuddle🔗, being a developer event, had a lot of feature announcements and platform updates. The interesting thing? Almost half of the features manifested from developer feedback (Well, so did the tickets, but that's a story for another day😸). Talking about what we did for developers based on what they have asked for is a strong hook. It captures their attention and invests their mind into anything that follows.

As a rule of thumb, we start with insights from the previous event and proceed with an overview of the brand-new features that were derived from them.

✅ We made it easier for developers to share feedback online and offline. We have a dedicated developer forum, 'Connect with DevRel' program, and Partner talk sessions so that developers can reach out to us comfortably.

✅ Valid feedbacks are tracked from the source, consistently, until it reaches the right team. Updates are shared with the developers during events or via forums, completing the feedback loop. We try to under-commit and over-deliver.

💡 There is also an exciting announcement at the end of this post for startups, independent developers, and aspiring students. Stay tuned!

2️⃣ Why game the system when the system can be a game?

Liquid error: internal
As I said earlier, we didn't start with a perfect plan. However, we wanted to ensure that the participants felt engaged and included during each session. In fact, we themed these sessions like a game so that nobody gets bored! The participants were able to interact and live-code with the presenters during the demos.
Liquid error: internal

✅ Every session had live interactions. Collaboration tools such as Glitch, Mentimeter, and Kahoot proved to be immensely useful. Quizzes were interwoven with the content on-screen to make it highly engaging. This technique was so powerful that we maintained an audience retention rate close to 96% over 2 days

✅ Quizzes and polls started very light and gradually proceeded to be highly relevant to the sessions. Participants were rewarded for listening and getting the answers right. This enabled us to not only have fun but also to strengthen content absorption! (Also, It helped me with Netflix series recommendations 😅)

Hem

@hemsays

We took a quick break and stretched out for the `Design Exercise` session. Guess who was the presenter?

Me 🥳! And yes, I did start with sourcing Netflix series recommendations 😅

We also ran a rapid-fire quiz to reward our participants at the end of the session 🏆

15:43 PM - 15 May 2020

✅ Making the best use of tools at our disposal was essential. We made use of Zoom and took complete advantage of the capabilities that it offered - Breakout rooms, Webinars, Chat, and audio share. Orchestrating them worked wonders.

3️⃣ Collaborative coding is a thriller! It is almost a sport:

Having delighted the developers, it would be unfair to lower the bar later on. Thanks to Glitch, Freshworks Developer Kit (FDK) was made collaboration-ready back in 2019 itself. In no time, almost all the participants jumped into the live editor and started developing the app, in parallel.

Yes, you heard it right, in parallel.

Liquid error: internal

✅ The App development setup was moved online making it easy for people to start coding right away. We saved a ton of time by moving the Freshworks Developer Kit to Glitch so that people don't have to spend time setting things up.

✅ Collaborative coding turns out to be more adventurous than quizzes. We defined what needs to be done before the start of the demo and participants hacked their way into getting it right! At one point, it became as entertaining as watching football.

All of this productivity was possible because we ensured near-zero time-to-value. Simply put, Time-to-value (TTV) is the time taken to achieve something useful.

If a product or platform can offer value to the developers in a really short time, it is a sure-shot sign of success.

Hem

@hemsays

Next up, we had @rohithjayaraman presenting @freshcaller app development! He put on a great show with one of the seasoned platform developers - Ilya @belyavskiy. The duo made live coding as interesting as a football game!

🍿Next time, I am grabbing some popcorn!

15:44 PM - 15 May 2020

We also tried collaborative solutioning through Excalidraw (live whiteboard) where we worked on design challenges together with the participants. We had a Design Excercise session where participants collectively solved and arrived on solutions for app scalability challenges.

4️⃣ Putting developers on the spotlight:

Recognizing developers for their efforts and celebrating them inspires great work. Passionate developers are a rare breed. If we aren't paying enough attention to them, they will most likely lose their enthusiasm. This is literally the last thing that anyone would want in a growing community.

Liquid error: internal

✅ Many of our partners were invested in the initiatives and the early access programs that we rolled out before the event. We ensured to recognize their work and reward them with goodies.

✅ Similarly, we also opened the stage for partner developer talks. Historically, we have had talks lasting for more than the allotted time because fellow developers could easily relate to challenges and approaches to solve the same. This also evoked a strong sense of community.

Hem

@hemsays

We open up the stage for developer talks. Akshay Kulkarni & Alisha from @Artissol_inc present an amazing session on how they made the best use of platform features and product REST APIs in their app 👏

15:44 PM - 15 May 2020

5️⃣ Teamwork is everything:

All of this good work wouldn't have been possible without a great team. We were able to apply what we learned from the past. We were provided with enough space to experiment. This ensured we were data-informed and strategy-driven.

Liquid error: internal

✅ Almost everything that we learn or discover is documented. Similarly, we retrospect on the events and document key findings and insights. There is a free flow of knowledge within the team.

✅ Being empathetic is a key trait of DevRels. This is extremely important when it comes to events as well. We view things from the perspective of developers and our coworkers. This aids in quality decision-making. It is important to note that being empathetic does not mean agreeing to everything. We have a healthy & constructive level of critique as well.

Now, that being said, as I promised earlier, I have an interesting announcement for independent developers, startups, and students who are willing to benefit from the Freshworks App ecosystem 👇

Hem

@hemsays

Developers, Students & Startups can benefit from the Freshworks ecosystem through co<div/> and can potentially kick-start their future businesses.

You can reach out to me, @Saif_Shines, or @juhi_singh15 for further details.

15:45 PM - 15 May 2020

In light of the current situation, we wanted to empower developers who are willing to learn and build powerful apps for Freshworks products. In a way, we wanted to turn the COVID situation on its head - Making it an opportunity. Hence, co<div/> 🥳. We are also having a hackathon at the end of the program ♥️. If you are interested, feel free to check it out!

Hope you found this article useful. I will keep you posted on our future DevRel adventures as well. Also, I am open to hearing your thoughts on what worked out in your virtual event too!

🐨🎤[GIF] Cheatsheet for Javascript Nullish Coalescing operator

Hem — Mon, 20 Jan 2020 11:18:09 +0000

Good day folks! 👋 Today, we are going to cover something small, yet, an important feature in Javascript. In this post, we will see how Nullish Coalescing or Nullish Koala-sing 🐨🎤 (whichever sounds good 😅) works using GIFs.

👇Things to note before we get started:

Short-circuiting is denoted by ⚡️
At the time of writing this post, Nullish Coalescing was a Stage 4 proposal

Alright, let's get started with the different scenarios of its usage

Scenario 1 (Base case): If the expression at the left-hand side of the ?? operator evaluates to undefined or null, its right-hand side is returned.

Scenario 2: Behavior of Nullish Coalescing ?? operator with falsy Javascript values.

Notice how short-circuiting (denoted by ⚡️) happens when the LHS is null or undefined. It doesn't matter if the LHS is falsy values except for null and undefined

Note: Explicit parentheses groups are required to mix with || and &&

Scenario 3: When mixed with other short-circuiting operators || and && without parentheses

Scenario 4: When mixed with other short-circuiting operators || and && with parentheses groups

That's it for today and I hope you found it useful!

And hey, I ❤️ learning from and staying in touch with the curious folks out there (I'm looking at you. Yeah, YOU!). So, please feel free to reach out if you have any questions or suggestions 🙋‍♀️🙋‍♂️ I'm all ears 🤩

🐥Twitter	💼LinkedIn

Auf wiedersehen 🙌🏼

Repo Link :

hemchander23 / javascript_in_gifs

Javascript concepts and features visualised in the form of GIFS. I use it for my own reference. Glad if it was useful for you !

Javascript in GIFs 🎉

Do you find the documentation hard to understand ? Worry no more, the GIFs got you covered!

Feel free to contribute ❤️

View on GitHub

🚀 [GIF] Cheatsheet for Javascript Promise API methods - Promise.all, Promise.allSettled, Promise.race, Promise.any

Hem — Mon, 13 Jan 2020 12:57:36 +0000

Hello everybody 👋! I created this GIF cheatsheet for my own reference and I hope it will be useful for the community as well ❤️

Index

How is this organized?
Promise.resolve,Promise.reject
Promise.all
Promise.allSettled
Promise.race
Promise.any

How is this organized?

Consider the GIFs like watching a slow-mo video of Promise API methods in action. The scenarios for each Promise API describe how they work with an emphasis on Promise status transition, value/reasons, and the order.

Color Code	Promise Status	What it means
	`pending`	Represents initial state. The operation represented by the promise is neither fulfilled or rejected.
	`fulfilled`	Operation is successful and result value is assigned. Typically, values appear on top of the respective promises upon fulfillment
	`rejected`	Operation unsuccesful and usually there is a reason for rejection. It appears on top of the rejected promise

For the sake of simplicity, I have added numbers below each promise representing the order in which they settle. This is handy while understanding the short-circuiting behavior (denoted by ⚡️) of each promise API.

`Promise.resolve`

Scenario 1: If the given value is not a thenable but a valid Javascript value

Scenario 2: If the given value is a thenable (i.e., Promise or object with then() method

Scenario 3: Nested Promise-like objects

`Promise.reject`

Scenario: Rejection with a reason

`Promise.all`

Scenario 1: All passed-in Promises get fulfilled

Scenario 2: ⚡️ One or more of the passed-in Promise(s) rejects

Scenario 3: ⚡️ All passed-in Promises get rejected

Scenario 4: Passing an Empty iterable

`Promise.allSettled`

Scenario 1: All passed-in Promises get fulfilled

Scenario 2: One or more of the passed-in Promise(s) rejects

Scenario 3: All passed-in Promises get rejected

Scenario 4: Passing an Empty iterable

`Promise.race`

Scenario 1: ⚡️ All passed-in Promises get fulfilled

Scenario 2: ⚡️ One or more of the passed-in Promise(s) rejects

Scenario 3: ⚡️ All passed-in Promises get rejected

Scenario 4: Passing an Empty iterable

`Promise.any`

⚠️ Warning - Promise.any() method is experimental and not fully supported by all browsers. It is currently in the TC39 Candidate stage (Stage 3).

Scenario 1: ⚡️ All passed-in Promises get fulfilled

Scenario 2: ⚡️ One or more of the passed-in Promise(s) rejects

Scenario 3: All passed-in Promises get rejected

Scenario 4: Passing an Empty iterable

And hey, I love staying in touch with the curious folks and learning from them as well! ❤️ So, Please feel free to reach out if you have any questions or interesting thoughts 🙋‍♀️🙋‍♂️Don't forget to share this post if you found it useful 🚀

🐥Twitter	💼LinkedIn

Repo Link :

hemchander23 / javascript_in_gifs

Javascript concepts and features visualised in the form of GIFS. I use it for my own reference. Glad if it was useful for you !

Javascript in GIFs 🎉

Do you find the documentation hard to understand ? Worry no more, the GIFs got you covered!

Feel free to contribute ❤️

View on GitHub

🥋Few tips to make developers not wrestle with your APIs

Hem — Wed, 01 Jan 2020 18:23:51 +0000

Often, APIs are the first point of contact for developers and significantly impact Developer Experience(DX). Developer-friendly APIs will improve adoption, retention and might also instill a good word-of-mouth awareness among the developer community. At the end of the day, an API has to provide an interface using which products/ applications can talk to each other. Adding a few more traits to this baseline definition does not only deliver a good interface but also provides a great developer experience.

1️⃣ Documentation

This is the first and foremost factor for successful APIs. Neatly documented endpoints with clear descriptions enable developers to understand and leverage them easily. Interactive API documentation stands out and is beneficial when you have a lot of APIs to offer. At the minimal, the capability to try it out in POSTMAN or other REST clients could save time for the developer and can make things easier.

Good documentation also covers things that the developers might miss hurriedly (most probably during their 1st pass) for example - rate limit policies, paginations, authentication, etc. It should drive developers towards the pit of success by default

2️⃣ Graceful changes, deprecations

Change is inevitable. It is good for progress. However, it becomes our duty to convey changes to developers as and when they occur. Most importantly, being mindful of users who have already consumed the API and introducing changes gracefully can alleviate major issues.

Communicating it via developer portals, changelogs, forums, etc. will significantly reduce friction.

3️⃣ Proper Error response/Status codes

I wish to live in a world where there were more 418-like status codes. However, it is always recommended to stick to meaningful error codes that convey upfront information to the user without them having to sherlock it.

Developers will be able to connect the dots and solve the issue at a much lesser time if the error code makes sense. The advantage of such status codes is that it implicitly delegates problem-solving to the developer and makes them informed in that situation. Otherwise, this might end up as support tickets and forum queries.

4️⃣ Avoid too chatty/chunky

Chatty APIs will lead to making multiple network calls to perform a single task. This ideally should be one single API call. On the other hand, chunky APIs end up providing too much information in one single call. It is recommended to avoid the extremes

These are a few tips that I follow to ensure that developers don't wrestle with the APIs. I would like to hear your thoughts as well in the comments section! 😀❤️

DEV Community: Hem

🔑 OAuth 2.0 flows explained in GIFs

Hold on, what's OAuth❓

Terminologies 🧱

Flows in OAuth 2.0

1. Authorization Code Grant flow

2. Authorization Code Grant with PKCE

2.1. Transformations - Meet SHA256

2.2. How do we generate the Code Challenge (CC) from the Code verifier (CV) ?

PKCE flow

3. Client Credentials Grant flow

4. Resource Owner Password Credentials Grant flow

5. Implicit Grant flow

👩‍💻👨‍💻Running a Highly Engaging Virtual Developer Event

1️⃣ Developers love features, but more so when it's feedback-driven:

2️⃣ Why game the system when the system can be a game?

3️⃣ Collaborative coding is a thriller! It is almost a sport:

4️⃣ Putting developers on the spotlight:

5️⃣ Teamwork is everything:

🐨🎤[GIF] Cheatsheet for Javascript Nullish Coalescing operator

hemchander23 / javascript_in_gifs

Javascript concepts and features visualised in the form of GIFS. I use it for my own reference. Glad if it was useful for you !

Javascript in GIFs 🎉

Contents

🚀 [GIF] Cheatsheet for Javascript Promise API methods - Promise.all, Promise.allSettled, Promise.race, Promise.any

Index

How is this organized?

Promise.resolve

Promise.reject

Promise.all

Promise.allSettled

Promise.race

Promise.any

hemchander23 / javascript_in_gifs

Javascript concepts and features visualised in the form of GIFS. I use it for my own reference. Glad if it was useful for you !

Javascript in GIFs 🎉

Contents

🥋Few tips to make developers not wrestle with your APIs

1️⃣ Documentation

2️⃣ Graceful changes, deprecations

3️⃣ Proper Error response/Status codes

4️⃣ Avoid too chatty/chunky

`Promise.resolve`

`Promise.reject`

`Promise.all`

`Promise.allSettled`

`Promise.race`

`Promise.any`