DEV Community: Bearer Engineering

Tips for Running an Effective Virtual Offsite

Bearer Engineering — Fri, 28 Aug 2020 13:20:24 +0000

📣 This post originally appeared as Tips for Running an Effective Virtual Offsite on The Bearer Blog.
Offsites are a big part of remote teams. They allow everyone to socialize, connect more deeply with coworkers, and help build shared experiences and empathy. Even if video calls are a great tool to share information, they can be tiring. It's too easy to miss non-verbal cues. Chance encounters over coffee never happen, and we don’t always experience the same personal connections that come from small-talk. That’s the downside of remote work, and that's why meeting a few times a year is a great way to fill the gap!

Planning an offsite can be challenging, but it also provides the opportunity for your team to explore an exciting place. With many teams looking for ways to mimic the traditional offsite in a limited-travel world, here are a few tips we learned after holding our first virtual offsite.

Context

The Bearer team is remote-first. Other than a few Bears that live in the same region, most of us only see one another digitally. This is why we put an emphasis on consistent offsite events. Shortly before COVID-19, we held one in France. Before that, the team met up in Portugal. The number of offsite photos used as Zoom backgrounds tells me that the team really enjoys them!

Because of the COVID-19 crisis, we couldn’t organize the offsite we were planning for Q2. Travel was more difficult, but beyond that, we wouldn’t have taken the risk of putting our coworker’s health in jeopardy. Our first thought was to cancel it, but we decided to experiment with a full-virtual offsite. A remote, remote offsite that we dubbed Together Week.

Start with a mix of work and play

We came up with a lot of ideas to make this week enjoyable and took inspiration from Hotjar’s article on virtual team building. We also had a nice chat with Bele Schütt from Candis who organized a remote offsite day a few weeks before ours.

The first question that came to mind was: if we miss the human interaction component, what should we focus on? This would be a time to take a step back from our daily work, mix up the normal team dynamics, and work on “something different.” The offsite should allow everyone to take time to experiment, far from the usual roadmap.

Set a theme, a task, and a goal

We put together teams made up of members from each department and set them a task to complete by the end of the week. Our project theme became: How can we attract more top-notch developers to test and adopt Bearer. Aside from the hard-limit on planning and presenting, no constraints or restrictions were set on what or how a team could approach the theme.

Our teams shared the work, discussed, debated, and built solutions throughout the week. All the teams did a great job. We aren’t just saying that. On Friday, each team had the opportunity to present what they spent the week building. Not only were the presentations amazing, but all the ideas have found their way onto future roadmaps at Bearer. It was great to see how impressed everyone was by each other's work!

While we initially planned to offer a prize to the winning team, the quality of work made it impossible to choose.

Instead of selecting a single winner, we decided that everybody won. Everyone at Bearer will receive a beautiful pair of hand-made slippers as a souvenir. The perfect treat for working from home!

Incorporate social activities and outside voices

Make the week special. On top of a hackathon or special-projects sprint, incorporate time for both structured and unstructured socializing. Find ways for to increase team bonding without making it feel like a chore. Here are a few things that worked well for us.

Guest Speakers

To bring in some fresh ideas, we invited external speakers to share their experiences. A huge thank you to Sylvain Kalache from Holberton School, Maxime Locqueville fromAlgolia, Rodolphe Dutel from Remotive, and Josh Dzielak from Orbit. Each came, virtually, to speak with the team. We learned about great remote routines, tips for working in multicultural teams, and advice on building a nice developer experience and community.

Make sure to record each session for those that cannot attend live. Spreading these throughout the week is a great way to inspire and keep the team motivated!

Team meals and coffee breaks

To help with the missing social aspect of offsites, ask everyone to take virtual coffee breaks during the week. More specifically, we encouraged our team to meet with someone they don't work with often. Some team members made small talk and used the time to catch up. Others got into discussions about quarantine life, and some used the questionnaire answers and guest speaker talks as conversation starters.

The team also scheduled a few “happy hour” style events across different time zones. We tried to align them so those starting the day could share coffee and breakfast, while those ending the day could share drinks and dinner.

Virtual Escape Game

Early on, we decided against many of the “game” style team building activities for fear that they would be stressful for some, and difficult with Zoom. One that we did try was a virtual escape game. The team split into groups of roughly 6-8 people, and an outside facilitator set every person a task. We all had information to share and the goal was to crack our individual codes, then combine our information to save the world! For some of us, the puzzle was quite challenging, and the discussions carried over into the after-work happy hour!

Make it work from anywhere

Make sure everyone can take part, no matter their location and time zone. This should be obvious for a remote team, but offsites are so often thought of as a way to break the rules, that it can be easy to forget. With team members in Bangkok, South Africa, the United States, and spread across Europe, the challenge for our team was high! This meant enforcing asynchronous communication and documenting everything.

Set up shared workspaces if you haven’t already. We use Notion, Miro, and Slack heavily within the teams. Each team set up dedicated channels and documents for the week’s tasks. We also put together a company-wide channel in slack dedicated to the offsite. This keeps the normal work channels clear, but also acts as a nice archive of the events.

Be as asynchronous as possible, within reason. Sometimes it really helps to get together. We let each team manage their own meeting times. Teams were assembled so there was at least an hour or two of overlap to allow for daily check-ins as needed.

Record any “live” chats and alternate the scheduling. Earlier we talked about inviting speakers. When scheduling these, try to mix up the times to allow everyone to attend some of them live. For those that cannot make them all, record the sessions for later viewing.

Make support available throughout the process

For our hackathon-style task, we paired up teams to provide feedback and support. Team A was in charge of feedback for Team B, Team B for Team C, and so on. This gave teams fresh eyes and a sounding board for their ideas. An approach such as this encourages teams to interact more and keeps the feedback loops efficient.

We also had a handful of people within the company working outside of the hackathon structure. In particular, our founders Guillaume and Cedric. They made themselves available to the teams throughout the week, and offered support and ideas from a higher-view perspective. Some teams took advantage of their insight more than others, but all found the direct input throughout the process useful. Designate managers or others to ensure you have coverage and can support the teams in any way they need.

Use this time to improve team resources

Improving team dynamics and social experiences within remote teams is one of the largest benefits of a traditional offsite. That doesn’t mean the same ideas can’t help inform your day-to-day processes. For example, we decided to create a page in Notion where people can share more about themselves. To make it easier, we used a mix of Proust questionnaires, user manuals, and work-related questions. The team has been very creative in the format. As the last hire in the team, I enjoyed reading each of the descriptions and found some common talking points to discuss with the team soon. I’m sure the new hires will enjoy it as much I have!

Create a shared experience

One way to further make everyone feel connected around the event is to send out a care package. This can be a kind of onboarding box that arrives before the week begins. In this box, each person will receive what they need for the week. Things like: a notebook, an interesting book to read, some snacks, and maybe even some instructions for a treasure hunt.

While time constraints and logistics prevented us from doing it this time, we feel like it’s a great way to reward the team, and set a tone for the week. Not to mention it is a great excuse to print some new company-branded gear! You don’t even want to know the number of Bear-related puns we came up with during the offsite. Some were _unbearably_bad.

Look for ways to improve future offsites

No amount of planning will make for the perfect event, so make sure to solicit feedback from your team. What worked for them? What did they enjoy the most? What would they change? Overall, we received very positive feedback from the team, which was our main goal. We wanted people to have a good time and to work differently.

We also received some valuable constructive feedback. One item that stood out was making sure the games were accessible to non-native English speakers. Solving anagrams is hard enough when they are in your native language!

Core things to keep in mind

We learned a great deal from our first virtual offsite. While it can’t completely replace the enjoyment of all getting together in an exciting location a few times a year, it gets about as close as you can.

If you’re planning to organize a virtual offsite week, here are some tips to get you started:

Break into small groups to make sure the work part is enjoyable.
Virtual escape games are a really great option!
Invite people from the outside to learn from them: it’s the perfect time to open your minds!
See if there are any social, internal tasks you want to address that you never take the time to do, or those you want to experiment with. Have everyone fill out a bio, set up video game groups, launch a coffee break app, and improve your remote onboarding!
Make sure you’re clear on the expected outcomes: as soon as we agreed on the fact that it was okay not to have immediate results from the work of the teams, the fun and experiments really started.

With our first virtual offsite now completed, we are already thinking about the next Together Week and are dreaming of having the possibility to do it in real life! Stay tuned for photos of happy bears in cozy slippers.

By Marion Aguirre, Head of Talent @ Bearer

How to configure the imgur API

Bearer Engineering — Thu, 12 Dec 2019 17:42:41 +0000

This guide explains how to configure the Imgur API, using OAuth2.0 for authentication.

Overview

Sign in to your imgur account (step 1)
Create a new application (step 2)
Grab your credentials (steps 3)

Step by step

Step 1. Sign in to your imgur account. Imgur use the same account for their main website, as well as the developers portal.

Step 2. Once signed in, open the OAuth application registration form. From there:

enter your Application name
confirm that the Authorization type is OAuth2 authorization with a callback URL (default option)
register a redirect URL to handle the OAuth dance. Use https://int.bearer.sh/v2/auth/callback to let Bearer handle the authentication flow on your behalf.
provide an email

Step 3. Click save and that's it! Imgur will prompt your API keys right away.

💡 If ever you need to find your credentials again, they are accessible from your account settings.

Video guide

Follow along as we create a new application:

What's next?

You're now all set to build an awesome integration with the Imgur API. To help you get it through easily, here are a few more links:

Examples and tutorials curated by Bearer.sh
Create a temporary access-token with our generator
Learn more about the API in the official documentation

How to configure the Eventbrite API

Bearer Engineering — Wed, 11 Dec 2019 17:29:05 +0000

This guide explains how to configure the Eventbrite API, using OAuth, to use that API in your application.

Overview

Sign in to the Eventbrite developers platform (step 1)
Access the apps dashboard (steps 2 to 3)
Create a new application and grab credentials (steps 4 to 6)

Step by step

Step 1. Sign in to the Eventbrite Developers Platform. This is where Eventbrite helps developers integrate with the service.

Step 2. Hover over your profile and click on "Account settings" to access your profile.

Step 3. In the sidebar of your profile, scroll to the "Developer Links" sections and click on "API Keys". This is where you will manage your different credentials to authenticate with the Eventbrite API.

Step 4. Click on "Create API Key" to create a new OAuth2.0 application.

Step 5. Provide the details asked to save the OAuth consent screen, including:

Contact details
Application name and website
Register the URL you will use to receive the callback once the user logs into Eventbrite.

💡This information can change at any time.

Step 6. Save the form and that's it! Eventbrite will immediately create credentials. If you need to access them again, you can head back anytime to your apps dashboard.

Video Overview

As always, follow the same instructions to configure your Eventbrite API integration in this video:

What's next?

You're now ready to integrate natively with the Eventbrite API. To start building your integration, here are a few links:

Learn more about the API in the official documentation
Automatically monitor your integration with a monitoring tool, like Bearer

Understanding Auth Part 1: What is OAuth 2.0?

Bearer Engineering — Mon, 02 Dec 2019 18:09:15 +0000

(This article originally appeared on Bearer.sh)

In this series of blog posts, we will look at the varieties of OAuth 2.0, how OpenID Connect builds on top of OAuth 2.0 and fills in a few gaps, and the authentication and authorization ecosystem as a whole.

This first article is all about OAuth 2.0, so let's start with the difference between authorization and authentication:

Authorization relates to whether a client application has permission to access a protected resource. Authentication is about proving the owner of the resource is present, and obtaining information about their identity.

We'll try not to get too technical, but if the gory details are what floats your boat then stay tuned for future articles where we dive deeper into the specifics.

What is OAuth?

The OAuth 2.0 Framework is a standard for authorizing a client application to access protected resources.

The Client ID and Client Secret are what identify a client application. Together they are the known as client credentials and can often be found on the API provider's dashboard.

An API may expose many different resources, and many operations targeting those resources. The client can request limited access to the API by specifying a set of scopes during the authorization process. These scopes are specific to a given API.

A blogging API could use scopes such as read_posts, read_comments and create_post. A different blogging platform may prefer less granularity and offer only read and write scopes in its API.

When the client application completes the authorization process, it obtains an access token. This is then sent along with each API call as proof that the application is allowed to access the requested resource.

To limit the security risk of access tokens that are leaked or logged along with API calls, access tokens can expire after a period of time. The client application then has to go through the authorization process again to obtain a new access token.

Grant types

There are multiple flavors of OAuth 2.0 called grant types. Each one uses a different set of steps to obtain the access token, depending on the kind of client application performing the authorization.

Grant types can be broadly split into 2-legged and 3-legged variants. This refers to the number of parties involved in the authentication process.

3-legged grant types

The three-legged grant types are the most common and support delegating access to a protected resource that is owned by a third-party. The three "legs" are the client application, the API that the client wishes to use (subdivided into an authorization server and resource server), and the resource owner (typically an end user of the client application).

The three-legged grant types are designed such that the client never obtains access to the resource owner's credentials, or any information about their identity.

Authorization code grant

The authorization code grant type is the most common variant of OAuth 2.0

Use this grant type when:

The client application uses a web browser.
The client application is confidential. This is typically when the application is running on a server.

The resource owner's web browser performs a series of steps involving both the client application and the API's authorization server. This is sometimes referred to as the OAuth Dance.

Example: You may experience this grant type if you ever log into an application with another service's credentials, like LinkedIn or Google. The application never directly receives your login and password, but instead handles the process by communicating with the third party.

During this process, the resource owner authenticates directly with the authorization server and a short-lived code is returned to the client application. The client application then authenticates with the authorization server using the client credentials and exchanges the code for the access token.

Although OAuth 2.0 doesn't specify the mechanism of authentication that the authorization server will use, this usually follows a pattern where the user provides their login credentials and then consents to the requested set of scopes.

Implicit grant (not recommended)

Use this grant type when:

The client application uses a web browser.
The client application is public, e.g., when the application is running entirely within the browser, or when it's a mobile application.

This follows a similar process to the authorization code grant type but returns the access token directly to the client application via the browser, rather than using an intermediate code.

It is not recommended to use the implicit grant type as it is not as secure as other methods. One alternative is to use the Authorization Code grant type with the Proof Key for Code Exchange (PKCE) extension.

Device code grant

The device code grant type is an addition to the original OAuth 2.0 specification.

Use this grant type when:

The client application is not using a web browser, or lacks the ability for the user to input their credentials during the authorization flow.
The user has access to a web browser with sufficient input capabilities via other means, e.g., via a secondary device.

The client application makes an initial request to the authorization server and obtains a code and verification URL. The resource owner must then manually visit the URL, go through an authentication process, and enter the code. During this process, the client application polls the authorization server. When the process is completed, the access token is returned to the client application.

Example: You may have experienced this grant type when logging into a streaming service on a smart TV. The app gives you a web address and a code to enter, then you log into the service on your phone or computer. Once you enter the provided code, the app on your TV receives the access token and you can begin using the app.

2-legged grant types

The two-legged grant types involve the client application directly supplying the credentials to authorize. The two "legs" are the client application (which might also be the resource owner) and the API that the client application wishes to use (subdivided into an authorization server and resource server).

The two-legged grant types are typically used for machine-to-machine (M2M) authorization.

Client credentials grant

Use this grant type when:

The client application is accessing its own resources, or permission to access resources has been granted by the resource owner via another (non-OAuth 2.0) mechanism.

Using this grant type, the client application is able to obtain an access token using only its own client credentials (Client ID and Client Secret).

Resource owner password grant (not recommended)

Use this grant type when:

The client application is not the resource owner.
There is a high degree of trust between the resource owner and the client application.
A three-legged grant type cannot be used.

The resource owner provides the client application with a username and password and the client application uses these along with its own client credentials to obtain an access token from the authorization server.

It is not recommended to use the resource owner password grant type as it requires the resource owner to share their credentials with the client application

Refresh token grant

Use this grant type when:

A refresh token was returned from a previous authorization request.
The access token from a previous authorization request has expired.

When an access token has expired, the client application has to go through the authorization process again to obtain a new access token. For the 3-legged grant types, this would require the user to be present and to re-authenticate. For the 2-legged password grant, this would require the client application to store the user's credentials. This may not always be possible or desirable. To avoid this, many APIs return a refresh token along with the access token which can be used to re-authorize the client application.

Some APIs require refresh tokens to be enabled in their developer dashboard, or only return a refresh token if a special scope (e.g., offline_access) is requested when authorizing.

Using a separate refresh token to periodically renew the access token is more secure than having a long-lived/non-expiring access token. The access token is sent with every request for a protected resource and might be used in many places in the client application. Whereas the refresh token is only sent to the authorization server and its usage in the client application can be far more isolated. This makes it easier to secure the refresh token against being leaked and limits the window of opportunity if the access token were to be leaked.

Token introspection

The OAuth 2.0 specification defines a limited set of metadata (e.g., the access token expiry time and the granted scopes) that can be returned as part of the authorization process. There are other useful pieces of information that have historically been added as non-standard attributes in the authorization response, such as the refresh token expiry time. It's also possible that the information returned at authorization time may become outdated. For example, an access token could be revoked by the resource owner.

The OAuth 2.0 Token Introspectionstandard allows a client application to inspect an access token or refresh token at any time and retrieve up-to-date metadata about it. Some notable values that can be returned are:

Whether the token is still active.
The scopes that were granted.
When the token was issued.
When the token expires.
Who the resource owner is.

Example: For the Salesforce API, the expiry time of an access token depends on factors that cannot be known at the time of authorization, e.g., when the last API call was made. The token introspection endpoint can be used to check whether the token is still active and when it is currently expected to expire.

Conclusion

In the first part of this series, we looked at OAuth 2.0 and how it standardizes a wide range of authorization scenarios that are relevant to building and consuming APIs. Although there is still a lot of complexity in the details of OAuth 2.0, having a standard allows libraries, frameworks and services to help you manage this so you can keep your users' data secure and focus on the core business logic of your application.

Don't miss the next part in this series where we look at OpenID Connect and how it can be used to support "Sign in with Google" type functionality, and more! 🚀

Discuss this article on Twitter and ping us @BearerSH.