Free AI web copilot to create summaries, insights and extended knowledge, download it at here

Abstract

<figcaption>Authrization code flow with PKCE for the TeamCollab</figcaption></figure><blockquote id="894c">What actually happens in the PKCE is first the client will generate a code and Hash it (With SHA-256). Then sends the hashed result along with the request to the Auth server. Then later when client submits the authorization code, it must send the previously generated code (pure code before getting hashed). Then the authorization server will apply the SHA-256 and verify whether it equals to the previously received Hashed code(at the first request).</blockquote><h2 id="8d95">Why This Flow Matters</h2>Now, imagine if there was no Authorization Code Flow. You would be logging into TeamCollab and entering your Google email and password directly into TeamCollab’s app. This would lead to serious security risks:<ul><li>Credential Sharing: TeamCollab would need to store your Google username and password, making it a prime target for attackers. If TeamCollab is hacked, your Google credentials (and any other users’) would be exposed.</li><li>Overprivileged Access: Once you share your Google credentials, TeamCollab would have full access to your entire Google account — not just the parts you authorized. Without a way to scope the access (like tokens), the app could read all your emails, change settings, or worse.</li><li>No Revocation: If TeamCollab were compromised or you stopped trusting it, the only way to revoke its access would be to change your Google password, which would be a huge inconvenience.</li></ul><h1 id="90ca">2. Client Credentials Flow in TeamCollab</h1>Let’s say TeamCollab provides an automated backup service for companies. This service periodically backs up all team-related documents and project files stored in Google Drive to a secure internal storage system (within TeamCollab). Since this backup task needs to happen on behalf of the company and not on behalf of a specific user, no individual user needs to log in. Instead, TeamCollab itself acts as the client, needing access to the company’s Google Drive storage for this scheduled task.Here, we use the Client Credentials Flow, where TeamCollab (the client) directly requests a token from Google’s authorization server to access company files for backups.<h2 id="f07a">Step-by-Step Flow:</h2><ol><li>TeamCollab Identifies Itself: When it’s time to perform the backup, TeamCollab’s internal service reaches out to Google’s authorization server. Since there’s no specific user involved, it identifies itself using its client ID and client secret, which are like the app’s credentials. These credentials were issued by Google when TeamCollab integrated with Google Drive as a trusted client.</li><li>Token Request: TeamCollab sends a request to Google’s authorization server, saying, “Hey, I’m TeamCollab, and I need access to Google Drive for backups. Here’s my client ID and secret.”</li><li>Token Issuance: Google’s authorization server verifies TeamCollab’s credentials (client ID and client secret) and, if everything checks out, issues an access token.</li><li>Accessing the Resources: TeamCollab takes the access token and uses it to access the company’s Google Drive. It retrieves the documents and project files necessary for the backup and stores them securely in its internal storage.</li><li>Token Expiration: Just like in the Authorization Code Flow, the token has an expiration time. When the token expires, TeamCollab can request a new token using the same client credentials without any user intervention.</li></ol><figure id="aaac"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*LowSaXsXnHE5CKp4xzj8zA.png"><figcaption></figcaption></figure><h2 id="272f">Why Client Credentials Work Here</h2>Now, you might wonder: “Why is it okay to use a client ID and client secret to get a token in this scenario?”Let’s break it down:<ol><li>No User Involvement: In this scenario, no specific user is involved. The backup service is purely a machine-to-machine operation. It’s TeamCollab, as a system, interacting with Google Drive to retrieve files. Since no user is logging in, we don’t need to worry about user credentials, login screens, or handling sensitive user data.</li><li>Why Client ID and Client Secret are Safe: TeamCollab uses its client ID and client secret (think of these as app credentials) to authenticate itself with Google. These credentials are securely stored on TeamCollab’s servers and never exposed publicly. This is a safe and standard practice because:</li></ol><blockquote id="42be">It’s secure: The client secret is stored securely on the server, not shared with end users or exposed in insecure environments (like browsers or mobile devices).</blockquote><blockquote id="bc8c">No human interaction: Since this process doesn’t involve a user logging in, there’s no risk of password sharing or phishing.</blockquote><blockquote id="2ad3">Automated process: The service can run automatically without requiring any manual steps or user intervention, which is ideal for background tasks like backups.</blockquote>3. Machine-to-Machine Authentication: The Client Credentials Flow is designed exactly for this kind of use case where one system (TeamCollab) needs to authenticate itself to another system (Google) and access resources without any user interaction. This flow is perfect for scenarios like background services, data syncs, or system-level integrations where no human needs to be involved.<h1 id="6f32">3. Device Code Grant in TeamCollab</h1>Imagine TeamCollab is installed on a large smartboard in your company’s meeting room. Team members can use the smartboard to manage tasks, review project timelines, or even access shared Google Drive files during meetings. However, the smartboard doesn’t have a keyboard or a convenient way to log in. You can’t type in your email and password on a large screen, especially in front of everyone.In this situation, we need a way to let users securely log into TeamCollab on the smartboard, without directly entering credentials on the device itself. This is where the Device Code Grant flow comes into play.The Device Code Grant is designed for devices like TVs, smartboards, or other gadgets that don’t have an easy input method for typing usernames and passwords.<h2 id="ce2c">Step-by-Step Flow:</h2>1.Initiating the Login: A user walks up to the smartboard in the meeting room, taps on the TeamCollab app, and selects “Log in to TeamCollab.” Instead of showing a keyboard or asking for credentials, the smartboard displays a unique code (let’s call it a device code) and a URL like <a href="https://login.teamcollab.com/device."><code>https://login.teamcollab.com/dev</code>ice.</a> This can be put into a QR code and ask the user to scan the QR code with another device.2.User Action on Another Device: The user is instructed to take out their phone or laptop (something that has a proper keyboard and browser) and navigate to the displayed URL. There, they’re asked to enter the device code that’s shown on the smartboard.<blockquote id="ce6f">For example, the smartboard might show something like: “To log in, go to <a href="https://login.teamcollab.com/device">https://login.teamcollab.com/device</a> and enter the code: ABC123.”</blockquote><blockquote id="823c">Or else Scan the QR code which will navigate to the above url with the code embedded in the URL</blockquote>3.Authentication on a Personal Device: Once the user opens the URL on their personal device (phone or laptop) and it redirects the user to the login page. After they authenticate successfully. Here if user’s tries to access the Google drive files then the TeamCollab’s auth service will redirect the user to the respective Google’s login and then Google asks for their permission to allow TeamCollab (on the smartboard) to access their Google Drive and other resources.4.Granting Permission: After the user consents, TeamCollab’s Authorization server provides an access token to TeamCollab, which can then be used on the smartboard. TeamCollab automatically detects that the login process is complete and grants access to the user’s files and tasks on the smartboard. Here SmartBoard App keeps polling the TeamCollab’s auth service by checking whether user has logged in or not.5.Access Granted: The smartboard, now having received the token, can use it to interact with TeamCollab services without the user ever having to type in their credentials on the device itself. The user is securely logged in, and the smartboard can now be used to manage tasks, review files, and collaborate in real-time.<figure id="1e92"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*g3Y980sYElG-q7XtKD9yng.png"><figcaption>How device grant is used in a smartboard</figcaption></figure><h2 id="9dbb">Why Device Code Grant is Used Here</h2>The Device Code Grant flow solves a very specific problem: how to log into devices that don’t have a user-friendly way to enter text, l # Options ike smartboards or even TVs. Here’s why this flow is particularly useful:<ol><li>Input Limitation: Devices like smartboards or TVs aren’t designed for entering usernames and passwords easily. The Device Code Grant allows users to authenticate using another, more convenient device (like their phone or laptop) where they can comfortably log in and grant access.</li><li>No Credential Exposure: Since the user is never entering their credentials directly on the smartboard, there’s no risk of their password being exposed or compromised on a shared or insecure device. They’re only logging in via a trusted, personal device like their phone or computer.</li><li>Separation of Device and Authentication: The device code separates the login process from the device itself. The smartboard or other limited-input device just needs to display the code and wait for the user to authenticate on another device. Once the authentication is completed on the personal device, the smartboard is granted access, but it never sees the user’s password or other sensitive information.</li></ol>The Device Code Grant flow in TeamCollab provides a perfect solution for scenarios where users need to authenticate on devices with limited input capabilities, like smartboards, while keeping their credentials secure and the process user-friendly.<h1 id="7f15">4. Refresh Token Flow in TeamCollab</h1>Let’s say you’ve logged into TeamCollab through the web app using the Authorization Code Flow. You’re working on a project and accessing your Google Drive files via TeamCollab. The access token TeamCollab received from Google has an expiration time — let’s say it’s valid for one hour. After that hour, the token will expire, and you won’t be able to continue accessing your Google Drive files unless you get a new token.This is where the Refresh Token Flow comes in handy.<h2 id="47c1">How the Refresh Token Flow Works:</h2><ol><li>Initial Token Issuance: During the initial login (e.g., using the Authorization Code Flow), TeamCollab’s authorization server issues both an access token and a refresh token. The access token is used to communicate with Google’s APIs, and the refresh token is stored securely by TeamCollab for later use.</li><li>Access Token Expiry: After an hour, the access token expires. Normally, you would need to go through the entire login process again to get a new access token, but since TeamCollab was also given a refresh token, it can use this to renew the access token automatically.</li><li>Token Renewal with the Refresh Token: When TeamCollab notices that your access token has expired, it sends a request to the authorization server with the refresh token. The server verifies the refresh token and issues a new access token without requiring you to log in again.</li><li>Continued Access: With the new access token in hand, TeamCollab can continue to access your Google Drive files seamlessly, without interrupting your workflow or making you log in again.</li></ol><h2 id="c1ab">Why the Refresh Token Flow is Useful</h2>The Refresh Token Flow provides a smooth user experience by avoiding frequent logins. Here’s why it’s beneficial:<ul><li>No Need for User Re-authentication: Once logged in, the user can continue working without having to re-enter credentials every time the access token expires.</li><li>Long-Term Access: The refresh token allows TeamCollab to renew access tokens in the background, ensuring uninterrupted access to resources over extended periods.</li><li>Security: The refresh token itself is usually long-lived and can be securely stored on the server, minimizing the risk of exposure to the client or malicious actors.</li></ul><h1 id="9a12">Legacy Grant Types: Password Grant and Implicit Grant in TeamCollab</h1>When OAuth 2.0 was first introduced, some systems were still heavily reliant on users providing their usernames and passwords to third-party services. To enable a smooth transition from these old methods to OAuth 2.0, the Password Grant and Implicit Grant were introduced. These grant types provided a way for existing systems to migrate to OAuth 2.0, but over time, as more secure and robust flows were developed, they became legacy and are no longer recommended for modern applications.<h2 id="fe9f">1. Password Grant (Resource Owner Password Credentials Grant)</h2>How it works: The Password Grant allows a user to provide their username and password directly to the client (in this case, TeamCollab), which then sends those credentials to the authorization server to obtain an access token.<ul><li>In TeamCollab’s case: If we were to use the Password Grant flow, when a user logs into the TeamCollab web app, they would be asked to enter their Google username and password directly into TeamCollab. TeamCollab would then pass those credentials to Google’s authorization server and receive an access token to access the user’s Google Drive files.</li></ul>Why it’s not recommended This method exposes the user’s credentials to the client app (TeamCollab), which completely defeats the purpose of OAuth 2.0’s primary goal — avoiding the sharing of credentials with third-party services. It increases the risk of a security breach, as TeamCollab would now be responsible for handling and protecting user credentials, which could be exposed or misused.Why other grant types are better The Authorization Code Flow with PKCE ensures that the user’s credentials are never shared with TeamCollab. Instead, authentication is handled directly between the user and the trusted authorization server (like Google), which returns a token to TeamCollab. This keeps credentials secure and out of TeamCollab’s hands.<h2 id="3351">2. Implicit Grant</h2>How it works: The Implicit Grant is a simplified version of the Authorization Code Flow, where the access token is returned immediately without the need for exchanging an authorization code. This grant type was primarily designed for client-side (JavaScript) applications where storing a client secret wasn’t secure or feasible.<ul><li>In TeamCollab’s case: If we used the Implicit Grant flow for our web app, when a user logs in, TeamCollab would receive the access token directly in the browser after they authenticate with Google, without any further token exchange.</li></ul>Why it’s not recommended The Implicit Grant has security vulnerabilities because the access token is exposed directly in the browser, making it more susceptible to being intercepted by malicious actors. Since there’s no client secret involved, it’s easier for attackers to obtain access tokens and compromise security.Why other grant types are better The Authorization Code Flow with PKCE ensures that the access token is exchanged server-side, keeping it out of the client (browser) and adding an extra layer of security with the PKCE code challenge. This makes the entire flow more secure, especially for public clients like web or mobile apps.While the Password Grant and Implicit Grant served a purpose during the early days of OAuth 2.0 to help older systems transition, they are now legacy and deprecated for modern applications. By using secure grant types like Authorization Code Flow with PKCE, Client Credentials, Device Code, and Refresh Tokens, TeamCollab ensures a more secure and robust experience for its users.<h1 id="8606">You’ve Mastered OAuth 2.0 Grant Types!</h1>Congratulations! You’ve now got a solid understanding of the OAuth 2.0 grant types and how they apply to real-world projects, just like our hypothetical TeamCollab solution. Whether it’s securing a web or mobile app with the Authorization Code Flow with PKCE, letting backend services talk securely using the Client Credentials Flow, enabling device-based logins with the Device Code Flow, or keeping sessions alive with the Refresh Token Flow, you’ve covered the essentials of modern, secure access management.By learning how to apply these grant types in your applications, you’re not just improving the user experience, but also contributing to making the digital world a safer place. OAuth 2.0 provides a robust framework for ensuring that user credentials stay private, access is controlled and revocable, and different devices can communicate securely.As you continue building applications, make sure to choose the right OAuth 2.0 grant type for each situation. By doing so, you’re helping raise the bar on security standards across the web, creating a more secure environment for everyone.Thanks for taking this journey into OAuth 2.0 grant types with me! Stay tuned for another scenario-based article covering another exciting software engineering topic soon. Keep learning, keep building, and let’s continue making the world a safer and more innovative place together!Until next time! 👋</article></body>

How to Talk to Your Brother with Mental Illness

A brief pause can prevent you from opening more wounds

My little brother has been dealing with mental health problems for 14 years. Looking back, perhaps it’s been longer. But he experienced his first psychotic break, followed by his first hospitalization, 14 years ago, when he was just 18.

Over those years, we’ve developed a lot of baggage. He’s made trouble in the family a hundred times. So when my little brother calls and makes ambiguous statements or unreasonable requests, it’s easy to think the worst and jump to conclusions. In fact, whenever my little brother calls, my automatic thought process goes something like this: anxiety, confusion, assumption of the worst, anger.

On a good day, though, I don’t immediately act on that thought process. I wait a few moments before responding to him. I re-frame the statement or request in my mind, trying to understand it from his point of view: is there some way that what he’s saying could make sense? So that’s Step 1.

Step One: Pause to Consider Before Responding

Here’s an example that just happened this morning.

Yesterday, my brother had an appointment with a social worker. The goal was to secure a bed in a homeless shelter for the night. We had a text exchange at night that sounded like he’d been successful. Then at 6:30am, I got TEN TEXT BUBBLES which seem to say he didn’t get a bed but instead spent $500 on clothing at REI and thinks I previously promised to buy him a new phone.

They looked like this:

hey Sis!!!

I was just testing out my activity levels slash motivation

instead of following directions i got a lot done

including spending $500 at rei since that suitcase died immediately and i figured i would get the kind of clothes that fit into a backpack

soooo i also am ready to upgrade my phone / we talked about it a few times and you were enthusiastic about helping me at first and i was just biding my time but for real!

but at this point i’m practically moved in and know i already need help getting out and to stay off the computer except dedicated activities so so we should do it

i think you agreed initially because i asked when my bike got stolen

just to recoup losses

but yeah i was thinking about falling asleep near the apple store if you wanted to come by early and wake me up at 10 or 1030

backpack was $150 too -/ plus i stained my best pair of pants from goodwill -:/ eating a pizza.

My first impulse was to reply “I never promised to buy you a phone!!!” But after pausing to consider, I realized that wasn’t an important battle to fight. He can’t make me buy him a phone, so why bother trying to convince him that his memory is untrue? That I’m right and he’s wrong? That kind of argument is pointless and unproductive. He won’t agree with me. I won’t win. Better just to leave this thread alone.

My next impulse was to chastise him for spending money foolishly. My little brother has done this before. Spending sprees are a common symptom of mania. In fact, I was surprised he was even allowed to spend $500 at REI. There was a period of time when he was literally banned from the chain for buying so much stuff and then bringing it back to exchange for so much other stuff and then bringing that back to exchange, and on and on etc. etc. until REI just said, STOP! You aren’t allowed to shop here anymore.

But I guess they forgot.

So here’s a man who doesn’t have a place to sleep at night, and he’s spending all his money on expensive camping clothes and equipment. That’s not a good idea. Right? Not a good way to set his priorities? Perhaps not. But as I paused to consider, with my finger hovered over the phone, I realized once again that this was not a good place to take our conversation. I was not going to win this fight. He was not going to suddenly see the light. Besides, it’s his money. He’s allowed to spend it how he likes.

And considering it further, I had to admit there was some way his actions could make sense. I am not the expert on how to make my little brother’s life better. He is. He’s the one living it. After all, $500 could buy maybe a week and a day in a dirty, run-down, bug-infested SRO in San Francisco. Maybe it really IS better for him to have some durable clothing and a reasonable way to carry it around that will serve him for months on end (providing he doesn’t lose them). But even if it isn’t, shaming him will not make it better. It will not result in different behavior. It will not get his money back. It will only result in both of us feeling upset and angry. So I quashed that impulse, too.

Then I thought hard about what we should be talking about. That’s step two.

Step Two: Choose One Good Topic to Focus On

When conversing with people with mental health issues, it’s a good idea to focus on one topic at a time, to limit tangents. My next impulse was to ask about his housing situation; and that one, I realized, was good. Housing is the most important thing for my little brother. Does he have a place to sleep at night where he can be safe, warm, and clean? Once I’d identified the most important and least contentious topic, I was almost ready to respond.

Then it dawned on me, finally, that if he hadn’t slept in a shelter, he’d been outside all night, which must have been pretty stressful. If anyone else I knew had to sleep outside in San Francisco for a night, I would express sympathy. And that’s step three.

Step Three: Express Sympathy

Instead of blaming my little brother for making foolish choices and failing to show up for or otherwise reserve a bed in a shelter, I decided to treat him at least as well as I would treat a casual acquaintance by expressing sympathy for his plight. So after pausing to consider, choosing one good topic to focus on, and deciding to treat my little brother with kindness instead of blame, I wrote this:

What do you mean “instead of following directions?”

Sorry the bag broke. Lame.

Are you approved for a shelter?

The conversation went on and on, and it took awhile to get the facts straight. It turned out he had walked all night, racking up 30 miles on the fitness tracker on his phone. That’s probably what had broken his flimsy rolling bag, which I’d bought in Chinatown, and which wasn’t built for that kind of heavy duty. As a solution, he’d bought a new backpack and gotten rid of half his clothes, including some pretty good shoes I’d bought him recently, since they wouldn’t fit inside the pack. :(

At first, he told the story in a way that made me think he’d chosen to stay outside all night instead of accepting a bed at a shelter, which I automatically responded to with anger and upset. But the force was with me this morning, so I didn’t express those emotions. I waited, probed gently, expressed sympathy. And as a result, I eventually found out that he’d missed the call from the shelter while his phone was recharging, and they hadn’t answered when he tried to call back.

So it hadn’t really been a choice, after all. He’d just framed it that way to put a positive spin on it. And my initial assumption that his carelessness was costing me money (via the abandoned shoes) and putting him in unnecessary danger had been incorrect.

And considering it further, I had to admit he might even be right! I am not the expert on how to make my little brother’s life better. He is. He’s the one living it.

Over the course of the conversation, there were many more opportunities to fight. Over and over, it seemed, he was baiting me. And maybe he was. He certainly knows me well enough to know how to push my buttons, and getting reactions from people is a time-honored pastime for him. But he also just might have been failing to communicate clearly. And it took me pausing to consider before responding — creating that small space of non-judgement — for us to reach some understanding, to bridge our divide.

At the end of the conversation, I’d agreed to meet him a little earlier than scheduled to have breakfast. And at the end of the day, he’d pinned down a place to stay for the week.

Thinking about this story reminded me of a course I took a few years ago in mindfulness, where the key is in the delay. Instead of letting your emotions run you, you take a moment to observe them and consider what to do about them. The idea is to recognize that you have an essential self, an identity, that is separate from your emotions. Your emotions pass over you, like clouds passing over the sun, and like good or bad weather, emotions soon change.

This story also reminds me of a book I read long ago about how to talk to people with mental health problems: “I Am Not Sick, I Don’t Need Help! How to Help Someone With Mental Illness Accept Treatment” by Xavier Amador. That book uses the acronym LEAP to remind allies of people who are struggling to Listen, Empathize, Agree, and Plan together, which seems similar the the steps I listed above.

Of course, everybody is different. And if you love someone who has a mental illness, you’ll develop your own customized ways to help.

According to the Substance Abuse and Mental Health Association, one in five people in the United States will experience a mental health problem each year. But everyone on the planet, whether struggling or not, could use a little more patience, focus, and sympathy. So I’m going to try to treat everyone better, starting with my beloved little brother.

For further reading…

No Apology Required

When to remember, when to forget, and why making amends isn’t always a good step

medium.com

They Will Release Him Tomorrow

But I’m not sure he’s ready to go home

medium.com

We Need To Reopen Asylums

My brother has nowhere else to go

medium.com

My writing is free to readers who follow my links from Twitter, Facebook, and LinkedIn, but if you’d like to read more, click here to join Medium for $5 a month and they’ll give me some of that money. For an email whenever I publish, click here. Find more stories about mental illness on this List. And for more of the good stuff, follow Fourth Wave, where we’re changing the world for the better, one story at a time. Got one of your own? Submit to the Wave!