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 and I think SAML is like a spaceship of the kreons from my latest dream I will open this note and find out that it's actually an authentication and authorization mechanism and not a kreon spaceship. Or maybe it is? ;)). Let's dig in below and find out!
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!
Security is mostly about correctness. You want to be sure who is that person/service you talk to (authentication). And you want to verify that that personal service is doing only what it's allowed to do. (authorization)
We are going to scan quickly the below terms:
1. Basic Authentication => When mama and papa thought about security. 2. SAML => When large corporates thought about security. 3. OAuth 2.0 => The foster child of mama, papa, and large corporates. 4. JWT => The startup kid buying a coffee paying with json 5. Tokens => Trading sheep for online services. 6. Authorization Bearer: <token> => The all mighty header. 7. Keys and $$$ => Give me the bottom line how do I make $$$ out of security.
This is as basic as it gets. You ask that user or service for something only he knows to prove his identity. We use the username and some secret, the password.
Basic authentication did not specify you need to encrypt the details you just need to base64 them. So it's clear text.
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 use encryption, https.
We finished with protocol number 1 basic authentication. Protocol number 2
SAML. (Security Assertion Markup Language).
Think if it as another protocol for authentication (like basic authentication) but it also supports authorization. Which means it would also tell what you are allowed to do.
SAML was originated in the days where XML was the king so it's not surprising 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 identify provider, is much different than buying a coffee even if it smells really good!
This is the grocery store, it's interested in selling me groceries, not about identity management, so it will use the identify 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.
SAML provides standard
SingleSignOn so you can use your same identity to sign on to multiple sites, that's cool, that's 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.
By digitally signed it means 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, shouldn't 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 auth
I repeat oauth2.0 is not an authentication protocol it's about authorization. This does not mean however we do not use OAuth for authentication, OpenId is a protocol on top of OAuth2.0 which serves for authentication.
You use oauth2.0 for allowing services to check if you or services are authorized to do operations.
OAuth does not internally encrypt anything, it does not demand you for, it does not enforce you to use https or another encryption mechanism, but you might find yourself using these, but just remember there is no https or encryption built-in inside the protocol itself.
Remember credentials? username/password? forget about them, we now use tokens instead. This is the same, you have some key which is like your username and you have some secret key which is like your passwords, say tokens do not say username password although it's pretty much the same.
In OAuth1.0 you needed to sign it call oauth 2.0 simplifies it with the token provided to you-you just pass along this token no need to resign.
You use access token and/or a refresh token in order to renew your access token.services.
So basically to get a new access token you just call getAccessToken with an input refresh token to get the new access token to access the services.
In basic authentication, OAuth, and wherever you go you will see this header:
Authorization: Bearer <access token>
You simply 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 authorization in the security data you put also some real data! for example "and I'm allowed to get a free coffee! - a claim". This is one of the greatest inventions of the 21st century (or not :).
JWT is simply an extension of OAuth 2.0 so it's like a foster child.
So you can specify with JWT that you are allowed to get a free coffee this is the "mindblowing" claim part.
Yeah we use again the boring
Authorization: Bearer <JWT>
You have 3 parts in JWT
- Header (metadata)
- Payload (coffee)
- Signature (it's me)
This is the protocol used to Hash the message.
HMAC - Hash with a secret key to generate signatures.
So JWT is about statelessness you pass the data from here to there and back it's all in the JWT
You pass the data in the JWT so you less need to store data in the server.
What do we use JWT for?
We use it for authentication ;)
We use it to pass security information!
This is because we sign the data so we know it was not tampered with!
username password for machines. Like bitcoin to dollars.
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 him $$$ for using your api! (he used the API key to access you, he should pay for that).