Forem: Benjamin Wanicur

Finding Effective Consultants

Benjamin Wanicur — Sat, 20 Apr 2019 18:12:37 +0000

Finding consultants can be a real challenge in today's market. This article is aimed at non-technical business owners or whoever might be in charge of hiring technical talent. When I say "consultant", I am primarily talking about programmers, but as we will see, it takes more than being a technically skilled programmer to be an effective consultant.

Holes In My House's Foundation

Sorry to bring out the tired house metaphor, but I still believe it is very appropriate for this kind of discussion. Every consultant I've met has their horror stories about inheriting an application with some serious technical problems. A side note to consultants here: Yes we have all been there, but "hindsight is 20/20" (or insert other cliche here). We do not know what was happening at the time, so try to reserve judgement about the previous programmers. But by all means, please be critical of the code!

Here is an example (one I've encountered a few times). The previous programmer(s) built a database that has problems in the way the data is organized. Then they wrote application code that runs on that database and its "less than desirable" organizational scheme. This is a really terrible situation because it costs exponentially more the longer it goes unaddressed. In this example not only do we need to fix lots of code, but customer data needs to be migrated (to the better organized database scheme). Customer data migration is a tedious and scary process.

Hopefully you do not find yourself in this situation. If you have a trusted friend with some techincal experience, you may be able to lean on them to help you find a technically competent consultant. I also believe this scenario is less common that other challenging situations (hint: read on) you might find working with consultants.

Rockstars, Gurus, and things that go bump in the night

So you have found your technical wizard and everything will be smooth sailing from here on, right ? If you've been following along you probably know I am going burst your bubble.

First let's take a minute to address some buzz words you should probably avoid when searching for consultants. Rockstar, guru, wizard are a few that come to mind. Looking at technical forums or email lists that allow recruitment posts, you will find that in the past few years these buzz words will ruffle many programmers' feathers and before you know it, the pitchforks and torches have come out. So why is that ?

In software development, it "takes a village". The tired cliche of a nerd, locked in room with red bull and year's supply of gummy bears has been played out and only belongs in TV or movies. Collaboration is king and no one knows everything. You might be thinking: I cannot afford to hire a team of programmers. I need one person who can do the job. I am not being literal with the term "village", so let's talk about the single consultant scenario.

Having your one "rockstar" consultant might work if the following are true:

You know exactly what features you need for your web application ahead of time
You are aware of the trade offs that different technologies or solutions present
You know that none of your requirements will ever change over the course of the project

If this is the case, go ahead and buy the red bull and gummy bears, lock your consultant in a room, and get ready for profit!

Ok... I've never worked on a project like that. Requirements always change. Most business owners are not aware of every technical trade off and rarely know how much work goes into each piece of their web application. If they did, they are probably a programmer and would do the work themselves.

Being a rockstar or guru developer alone is not enough be effective. I have talked enough about the challenges. Next, let's talk about how to find and work with effective consultants.

Effective Consultants

Being technically proficient should be the starting point for consultants. But it is just as important to become a trusted advisor and direct projects along paths that will lead to less heartache down the road.

It is vital to get consultants involved early in the process. I understand there is an impulse to save billable hours by handling the planning without a consultant's help. However, mis-steps at this stage can result in many hours of back tracking that might have been avoided.

There are no solutions, only trade offs. - Thomas Sowell

I know that sounds daunting, but it is very true, and I think it embodies the kind of advice you should be getting from your consultant.

Here is an example:

Client will ask what seems like a very simple, straight-forward question, like this: How much work would it take to make an autocomplete search bar on this page ? My answer starts a conversation that is probably more involved that my client thought. We have to talk about the pros and cons of each possible solution. We need to consider the end goal of the application. Is this a proof of concept application ? Is it something that needs to be ready for real-world consumer use when we are done ? How important is this feature compared to other features we want and how does that fit in with the budget ? Although this conversation might not have been the answer my client expected, I believe I am doing my job when we have these conversations.

Cry in the dojo, laugh on the battlefield.

Putting in the extra time by discussing the pros and cons of each decision can save hours and heartache later. I am very skeptical of consultants who are very tribal about their technologies. If consultant answers the question above (the autocomplete search example) with something like this: We should just use X because it is the best, please be wary.

Also beware the consultant who wants to build technology for technology's sake. They might want to try out this new framework because it is cool. Or over-engineer some solution based on an ego trip or some misconception about what a client needs to meet their goals. I think these scenarios are not very common for consultants who have been around the block more than once, but it is worth mentioning.

Finding Your Effective Consultants

Now that you know what to look for, how do you find these magical consultants ? I wish there were a tried and true method, but there is not. Even if you know from experience (perhaps a personal recommendation from a trusted friend) that a consultant is effective, we are all people with varying personalities and sometimes we clash.

Because of this uncertainty I am a big proponent of the Test Drive. Every large project can hopefully be broken up into smaller chunks. By "small chunk" I mean something that can be accomplished in few days of work or less. Once you have focused in on a potential consultant, see if you can find one of these smaller chunks and hire the consultant to complete the work. If the consultant is good and you have chosen something that is not a small chunk, they should be able to tell you that right away. Once the work is done, you should know if you like working with the consultant and vice-versa. If not, you should still have a chunk of completed work and you've only spent small amount of money.

I hope my opinions and thoughts about finding consultants has been helpful. If you have questions or want to chat, you can always reach me here.

OAuth2 Authorization Code Flow for Single Page Apps

Benjamin Wanicur — Mon, 15 Apr 2019 16:55:09 +0000

Original Post

You can implement the traditional OAuth Authorization Code Flow if you have access to both your SPA and backend server. This may be useful for supporting older OAuth providers.

Recently I was tasked with integrating several 3rd party services into an application. Most of these services use the OAuth2 protocol to handle authentication and authorization. I have worked with OAuth many times, but this was my first time integrating OAuth authenticated services into a Single Page Application (SPA) / backend micro services (API and more) architecture. Having to work with a backend API and SPA introduced some interesting wrinkles.

Single page apps might use the Implicit Flow for OAuth. The Implicit Flow is usually for client-side / SPA type applications when there is no access to the backend server. Maybe the app uses something like Firebase as a backend. The solution outlined in this article is using the Authorization Grant Flow. This approach will not be easy unless one has access / control of the backend server.

A FEW GROUND RULES:

This solution involves some redirecting and hence reloading of the SPA. If this is problematic or unacceptable for your needs, feel free to jump ship right now.
The registered redirect URI might not have the same domain as the SPA.
This solution assumes we are using JWT or some kind of token-based authentication for our own SPA application.

Implicit or Authorization Code Flow ?

This article is not attempting to address the question of which OAuth2 flow is best for your application. For SPAs it seems the industry has moved away from the Implicit Flow and over to using Authorization Code flow, with a public client. This flow is slightly different. No secret authorization code is exchanged (this is in Step 2 - see below). Since I had access and control over the backend services, I choose to go with the traditional Authorization Code flow.

Does this all sound like Greek to you ? If so, do not worry. We are not getting into the weeds of OAuth2 nor will we disappear down the rabbit hole of arguing about which flow is “the one right way”. The best solution depends on the goals of your application. This article is going to describe one solution.

Brief OAuth2 Overview

Even if everything written above is completely new to you, chances are you have used OAuth2 enabled applications. Especially if you’ve used any kind of Single Sign On buttons. Think about those “Sign in with (Google|Facebook|Github|etc…)” buttons you see all over the place.

When you go to authorize one of these applications, the first thing that happens is that you must authenticate yourself via username and password.

After you have proven that you are yourself, you must give the OAuth2 application permission to do various things on your behalf.

Once you have gone through the “OAuth2 song and dance”, the response from the OAuth2 provider should include an access token that we can use to access the 3rd party application. Maybe that includes giving our application access to a user’s Google contacts or emails. Or giving our application access to a user’s Facebook group.

One important OAuth2 detail. This redirect URL is something that needs to be registered ahead of time with the OAuth2 provider.

Here is an example from a Google OAuth2 config page, where localhost is used in the redirect URI. Note the "Authorized Redirect URIs section".

NOTE: Some OAuth2 providers will not allow "localhost" as a redirect domain. SSH tunneling / port forwarding can be used for development purposes to get around that issue.

The entire simplified flow looks like this:

You could imagine that this takes place somewhere on a configuration or settings page. When the user decides to "enable" a 3rd party service, behind the scenes the OAuth song and dance is happening. In the end we have an access token. And sometimes more...

Open ID Connect (OIDC)

Oh no! Another acronym. In official terminology OIDC is a “Profile” of OAuth2. That just means, it is like a “flavor” of OAuth2. What is important about OIDC is that we not only get back an access token, but we also get back an “ID Token”. This is a unique identifier that can be linked to our user.

When we get the response from our OIDC-enabled provider, we will store the id token and associate it with our user. In our workflow (see the next image), the user is already “logged in”, thus we can associate the ID Token with our user.

Single Sign On

The simple OAuth2 flow (described above) has already been handled. Therefore, we should already have stored the ID Token that was returned from Step 2. Now we have all the pieces in place, here is the big plan:

Now, let’s start from the beginning. The user clicks on our SSO button (“Login with Google”). If the user is already logged into Google, Steps 1 and 2 will happen transparently. If not, the user will have to authenticate with username / password.

The ID Token from Step 2 can be used to identify our user!

SELECT * FROM users WHERE <xxxx>.id_token = <ID Token>

This is pseudo-SQL. This article is not addressing how or where to store tokens

We now have our user! Our SPA is stateless and uses its own set of JWT tokens to authenticate requests. That means, for our user to be “logged in”, their requests need to be accompanied by a valid JWT token each time.

At this point, many cookie/session based solutions could be implemented, instead of this article’s solution. We could create and stuff the JWT token into the cookie and then the user will be “logged in”. However, there are some limitations with the cookie-based solution. For one, it only works easily if the SPA and Backend Server are on the same domain (frontend.myapp.com and api.myapp.com). There are ways around that challenge, however, our solution bypasses the need for cookies. We can also avoid other security concerns for cookies with this approach. Ok, we are not using cookies. What’s next ?

Step 3: We have identified the user. Why not just create the JWT and include it with the redirect back to our SPA ?

It turns out there is a major problem with that approach. The JWT token can be stolen and reused by nefarious users to impersonate your user. Therefore, redirecting our initial GET request back to our SPA (Step 3) with the JWT token included in the URL is unsafe. That URL will be in the browser history among other places.

Since we do not want to redirect back to the SPA with anything sensitive in the URL, we can create a short-lived, one-time-use token.

Step 4: The SPA will see this token in the URL. The SPA will immediately make a POST request to the Backend Server with the SSO token.

Step 5: The Backend Server will use the SSO token to identify the user, immediately invalidate the SSO token, and then respond with the JWT token securely in the POST body. User is “logged in.”

Good / Bad from this solution

Bad:

Redirects ? In many SPA situations the backend server has one job: output JSON. Since we are redirecting here, we break that simple rule. Now our backend server only outputs JSON…. except for this one time. In our case, I think this sacrifice was worth the gain.
An extra token to manage. It should only exist briefly, however, it is another moving piece that can break.

Good:

No cookies !
Stateless which is consistent with how many SPAs operate.
Using Authorization Code flow assures that older OAuth providers (who might not use encrypted data transfers) may only be accessible through this flow. Implicit flow (and OAuth2 in general) requires encrypted data transfer. This was the winning point in choosing this approach. It turns out that the project needed to support some smaller OAuth providers who were outdated and did not always adhere to OAuth's security standards.