Quick Guide to Sec: Basic Auth, SAML, Keys, OAuth, JWT, and Tokens
As the shift-left movement continues to gain steam, it's important for developers to be familiar with basic security protocols. Read on to get a dev's explanation!
Join the DZone community and get the full member experience.Join For Free
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:
- Basic Authentication
- OAuth 2.0
- Authorization Bearer
- Keys and Money
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.
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.
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.
In SAML, we have two parties.
- Service provider: You can buy a coffee from a service provider.
- 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!
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.
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.
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?
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.
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.
You use OAuth2.0 to allow services to check if you or services are authorized to do operations.
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
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.
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.
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.
Yeah, we again have to use the boring
Authorization: Bearer <JWT>
Header, Payload, Signature
You have 3 parts in JWT
- Header (metadata)
- Payload (coffee)
- Signature (it's me)
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.
What do we use JWT for?
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!
You can identify who is the caller application because you give each caller its own key.
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).
Opinions expressed by DZone contributors are their own.