Quick Guide to Sec: Basic Auth, SAML, Keys, OAuth, JWT, and Tokens

Here is what I learned last week about security.

If someone wakes me up in the middle of the night and tells me, 'Houston, we have a problem with SAML,' I would think SAML is a Kreon spaceship. But, as I've recently discovered, SSL is actually an authentication and authorization mechanism and not a Kreon spaceship (or maybe it is...). 

Security is one of those topics where you have so much of terminology going on, that it feels like you need a security dictionary. Below are some of the main terms and concepts in security.

Note: You already know what security is, you just need to connect the intimidating terms to what you already know about security from real life!

Is SAML a SpaceShip or a Type of Coffee?

Security is mostly about correctness. You want to be sure who a person/service you talk to is (authentication). And you want to verify that that person/service is doing only what they are allowed to do (authorization).

We are going to quickly scan the below terms:

1. Basic Authentication
2. SAML
3. OAuth 2.0 
4. JWT 
5. Tokens
6. Authorization Bearer 
7. Keys and Money 

Basic Authentication

This is as basic as it gets. You ask a user or service for something only they know in order to prove their identity. We use the username and some secret, i.e. the password.

Authorization: Basic Base64 (user, pass)

Basic authentication did not specify that you need to encrypt the details, you just need to base64 them. So it's clear text.

Cleartext! Use HTTPS for Encryption

But as it's cleartext you want to encrypt it, otherwise anyone on the wire or anyone with access to the service would be able to see your credentials. So you should use encryption and HTTPS.

SAML

We finished with protocol number 1, basic authentication. Protocol number 2 is SAML (Security Assertion Markup Language).

Authentication and Authorization

Think of it as another protocol for authentication (like basic authentication) but it also supports authorization. Which means it would also tell you what you are allowed to do.

XML

SAML originated in the days where XML was king, so it's not surprising the SAML protocol passes data for credentials and authorization with XML.

Parties

In SAML, we have two parties.

1. Service provider: You can buy a coffee from a service provider.
2. Identity provider: You prove who you are with an identity provider, it is much different than buying a coffee, even if it smells really good!

Service Provider

This is the grocery store, it's interested in selling me something, not about identity management, so it will use the identity provider to identify me in order to authorize and authenticate me.

Identity Provider

The identity provider is all about managing identities and what they are allowed to do.

Provides Standard SSO

SAML provides standard SingleSignOn so you can use your same identity to sign on to multiple sites, which is cool. This is just like how you use Google to sign in to different services, only this time it's the SAML protocol. You see, you already knew what SAML is all about.

Authentication Exchanged With Digitally Signed XML

By digitally signed, I mean we can prove who is the one that signed your authentication data.

Complex

Last but not least, SAML is more complex than modern SSO methods such as OAuth 2.0. So let's move on to OAuth 2.0, shall we?

OAuth 2.0

What about 1.0 you ask? It was more complex so we moved to 2.0 where we need to do fewer operations for our authorization.

NOT Authentication

I repeat OAuth2.0 is not an authentication protocol, it's all about authorization. This does not mean that we do not use OAuth for authentication, however, as OpenId is a protocol on top of OAuth2.0 which serves for authentication.

Authorization

You use OAuth2.0 to allow services to check if you or services are authorized to do operations.

HTTP

OAuth does not internally encrypt anything (nor does it force you to encrypt files), it does not enforce you to use HTTPS or another encryption mechanism, but you might find yourself using these, so just remember there is no HTTP or encryption built-in to the OAuth protocol itself.

Tokens Are the New Credentials

Remember credentials (username/password)? Forget about them, we now use tokens instead, which operate on the same general premise. You have some key which is like your username and you have some secret key which is like your password. So, while tokens do not use the terminology, 'username' and 'password,' it's pretty much the same thing.

Change From 1.0: No Need to Sign Each Call

In OAuth1.0 you needed to sign it with a call. OAuth 2.0 simplifies this with the token provided to you - all you do is just pass along this token, no need to resign it.

Access Token and/or Refresh Token

You use access tokens and/or refresh tokens in order to renew your access to token.services.

getAccessToken (refreshToken)

So, basically, to get a new access token you just call getAccessToken with an input refresh token to get the new access token in order to access the services.

Authorization: Bearer

In basic authentication, OAuth, and wherever you go, you will see this header:

Authorization: Bearer <access token>

You always use this header for your services' access.

JWT

This is the new kid in town and everyone thinks he is so cute! Why is that? Because of this great new invention, you don't only put authentication and authorization in the security data, you also put  some real data in! For example:

Extension of OAuth 2.0

JWT is simply an extension of OAuth 2.0.

Access Token With Claims

You can specify with JWT that you are allowed to get a free coffee; this is the "mindblowing" claim part.

Authorization: Bearer

Yeah, we again have to use the boring Authorization: Bearer <JWT>

Header, Payload, Signature

You have 3 parts in JWT

1. Header (metadata)
2. Payload (coffee)
3. Signature (it's me)

HMAC-SHA256

This is the protocol used to Hash the message.

Hash With the Secret Key to Compute the Signature

HMAC - Hash with a secret key to generate signatures.

Stateless Data and API Data Repassed From the Client

So, since JWT is about statelessness, when you pass data from here to there and back, it's all in JWT.

Instead of the traditional session on the server, you pass the data in the JWT so you don't need to store data on the server.

Usage

What do we use JWT for?

Authentication

We use it for authentication.

Secure Information Exchange

We use it to securely pass information!

Signed With Public/Private Keys to Verify Content Has Not Tampered With

This is because we sign the data so we know that it has not been tampered with!

API Keys

Identify Caller/Application

You can identify who is the caller application because you give each caller its own key.

Monetize API

Now that you know who called you, you can charge them for using your API! (they used the API key to access you, they should pay for that).

Resources

https://tomer-ben-david.github.io