We played with the Star Wars API and that was admittedly awesome. But what about when we're trying to find data/information that should be private some place? Thus, the joys (/s) of authorization

So remember those headers? There's a special one that's really common and it's called...... "Authorization". Very much surprising. There's a very simple version that uses a username and password combination. It's called.... Basic Authorization.

Programmers are such poets.

We don't want to just go sending our passwords in plain text out there on the internet right? It's just too obvious. But we do! All the time. Usually this is ok because you're sending your request through HTTPS which means securely encrypted in transit. Thank goodness.

Plenty of password schemas will let you add things like / or ? or & which would be totally fine most of the time. Except that from time to time, you'll be putting in those passwords as query parameters in a URL. And if you remember back to that, a & would totally confuse the recipient of the message, cause it would indicate you were trying to add another query param. What a mess right?

So, we use a beautiful little thing called base64 to encode the password (and usually the username too), so that all those special characters aren't present.

So let's play with base64 in our code!

async function main() {
    let plainString = "Hello world! & ? /";

    // here, this cool thing called buffer takes in some string and encodes to base64
    let endocdedString = new Buffer.from(plainString).toString('base64');

    console.log(`We turned "${plainString}" into: ${endocdedString}`);

    // here, buffer takes in some string, which we tell it is in base64 format, and send it back to ascii (normal lettering and stuff)
    let decodedString = new Buffer.from(endocdedString, 'base64').toString('ascii');;

    console.log(`And back again: ${decodedString}`)
}

main();

This shows how all those special characters get boiled down with magic to a little string that doesn't include them, but can be decoded on the other end.

If we were using this in a header, we'd end up with something like this

"Authorization": "{Auth Type} {actual auth string}"

"Authorization": "Basic SGVsbG8gd29ybGQhICYgPyAv"

There's some really really cool auth out there that makes thing way more secure than just this though. A problem with sending that same string above, over and over again on every single request you send, is that even though HTTPS is encrypted, if someone sees the same encrypted string over and over again, they can break it. So if you send 1,000,000 requests with SGVsbG8gd29ybGQhICYgPyAv every time, and that cool encryption stuff makes it look different in transit each time, it can still get hacked all the way back to your actual password.

Black hat hackers. Oh bother.

So what happens at RingCentral, is you actually do an exchange for a temporary auth token. You send your user name and password, just the one time when the app starts up. After that, you don't have to send your password again. And the auth token you use is only good for one hour. You get a separate refresh token that you can send each hour, to get a shiny new auth token. With this method, the likely hood that someone could get enough versions of your encrypted password is so small, that you don't need to worry about it. This is called OAuth.

Good job white hat hackers!

So when all that good stuff happens you get back an auth token, your authorization no says Bearer, instead of Basic. "Authorization": "Bearer oiuasgd87g2389u1ho qjdnas98dyiashbdoaishdig1923uyqoiskdniausgd9d8w1yoiahsd". I just slapped keys, but those bearer tokens are even longer than that.

There's really smart people out there who try to write about how the OAuth steps work. Here's a pretty good article on it https://medium.com/@darutk/the-simplest-guide-to-oauth-2-0-8c71bd9a15bb. I couldn't quote all the steps for you. And fortunately, we don't need to!

When companies make these awesome API systems, they'll often make a Software Developer Kit (SDK) that bundles up all this stuff to make developing as easy as possible. They want you to use these super pricy things they set up. The RingCentral SDKs handle these authorization flows quite nicely for you. Which is the next topic!!!