This article is all about different authentication/authorisation mechanisms such as Basic Auth, SSO, tokens etc.
First, what’s the difference between authentication and authorisation? Let’s start with a simple example. But how can I use examples without a little analogy, right? Let’s introduce our “actors”.
Imagine, there is a castle that we need to protect, because there are a lot of rooms there and some of them have safety boxes with gold coins in them.
We can’t let everyone in, so, we need to place some sort of a guard to make sure only certain people can come in. So, we find a dragon egg, nurture a dragon for ourselves and place it nearby to guard our treasures.
Scary… Good enough. Great! I resent the idea of addressing these magnificent creatures with neutral pronouns as if they were not people… So, my dragon is a he. After all, we are all entitled to choose our pronouns now, so why not grant this right to the beloved characters of most, if not all, fantasy and medieval stories? His name is Drogon, by the way (I am usually good at giving nicknames to pets, but this time I’d rather steal the name).
Now, lets see the process closer.
So, our dragon knows the faces of three people: its master, master’s child and a dragon carer. The dragon will let either of them pass, and will grill and chew on anyone else. It must be very lonely in this castle… .
- Authentication. This usually comes first, before authorisation takes place (if any). In our little scenario, when the dragon ð recognises his master, the authentication is performed.
- Authorisation. Once the master’s is established, the dragon lets the master through. He authorises the master to use the castle and whatever is stored in it.
So, to summarise, authentication is the process of establising the identity of someone, while authorisation is the process of establishing WHAT this identity can and can’t touch.
Username and Password
Let’s imagine that our dragon is not from the House of Dragons but rather from the Hobbit, meaning, he can talk. Now let’s imagine that when someone approaches him, he asks for the name and smells the trespasser. Of course, someone could just look very much like his master and dress alike, but if the smell is not right - the dragon will have a nice dinner ððĨ.
In the IT world, we would use a username and a password (smell) to get to the service we want. If we are in the system and the credentials a correct, we enjoy all sorts of contents this service provides. Otherwise… we don’t get grilled extra crunchy, but we are not let in either.
Basic Authentication
There are different ways to send username and password, one of them is to use the Authorization header and set its value to something. No one likes to pass credentials in plain text anymore (what a shame ð), so, the username and password are base64 encoded. That doesn’t improve security in any way, of course, but it is rather used to avoid any possible bugs if either the username or password contain special characters.
But how will the server know that these are username and password an not a token? Or something else? We just add Basic before the encoded string to give the server a hint:
Authorization: Basic c2hlcmxvY2s6Z29vZGpvYmNyYWNraW5ndGhlcGFzc3dvcmQsbWFu
Now, the server will know how to treat the value encoded.
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
You don’t need Basic Auth described above to use local authentication, for example and there are other means to send username and password (for example, in a POST body). That’s just one way of doing it.
Tokens
Why send username and password if we can send just password if we are sure it’s unique, of course. In our little analogy let’s assume that the dragon has several favourite toys. Trusted people are given a toy ð§ļ each, and they can show it to the dragon ð to avoid being sniffed and interrogated. The toy remains with them, and the dragon can play with it while the visitors are in the castle. But how do you get a toy? Well, you need to get sniffed at least once in order to get one.
In IT world, that basically means that we user our username and password to authenticate, and then we generate a token to use ongoing forward instead. While with the user and password I can do everything this user is allowed to do, the token might have reduced permissions. Also, if my token gets compromised, I revoke it and generate another one. When using services’ APIs it’s very common to use tokens. There are different types of tokens, they might have differnt expiration periods, and they can be passed in various ways, but they are still tokens.
Tokens are usually either random strings or pieces of information encoded and signed (JWT). Token can be stored on the server or be stateless (depends on the token). If the token is signed, we can avoid storing it on the server.
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
Simple Web Tokens
JWT (JSON Web Tokens)
RFC 7519, you can decode JWT tokens here - https://jwt.io/.
It’s relatively easy to spot a JWT token because they follow the same structure (base64 encoded):
- header. Usually starts with
eyJ...because it starts with{, usually, the same string ({"alg": "HS256","typ": "JWT"}). Contains info about the token and signature types. - payload (aka JWT claims). This is the custom part, contains information about the identity, maybe some information about the request iteslf. Not all of them need to be present, but here is the list of possible variables there:
- Registered.
- iat - C timestamp
- iss - who issued it
- sub - token subject
- exp - expiry time
- aud - (app URL or something indicating what this token is for)
- nbf - not before (before that time the token is not valid)
- jti - unique token id
- Public. Custom ones like
email,usernameetc. - Private. Look like garbage to everyone else, but mean a lot to the server. Like my self-made cards I gave to my parents when I was little ð.
- Registered.
- signature.
HMAC(header + '.' + payload, secret). Secret is stored on the server and is used to verify the token.
Each part is separated with a dot ..
I’m not quite sure how to stretch my analogy to encompass JWT tokens, to be honest. My dragon would have to learn how to read and verify signatures, which would effectively turn it into a notary, and where’s the fun in that?
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
Sessions, Cookies
Imagine, our dragon likes special cookies ðŠ with a little meaty touch. Suppose, when we have visitors who were sniffed already, we give them a cookie to give the dragon the next time they would like to pay us a visit. This way they can save themselves a emberassment of wetting themselved the next time the dragon is taking a closer look.
Let’s now see how that really works in a less frightnening situation. We use username and password to login and verify our identity. The server generated a cookie/session id. There are lots of different algoritms to generate those, we don’t really care about it here. All we care about is that this cookies is stored in the browser’s local storage and in the server’s RAM or the server’s local storage (this happens too). Hit F12 and go to the Application tab. You will see browser’s stash. There are three places where sessions ids can be stored, but usually it’s the Cookies storage.
When the user logs out or the session ID expires, it is deleted both on the client side and the server side.
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
OAuth (Open Authorisation)
Drogon ð will be playing the role of an resource server https://drogon.com and the master ðĩâðŦ is the authorisation server https://master.com. Now, the master’s son ðĪŠ wants to come through. Here is the play.
âïļ That’s not the most accurate representation of the process from the technical perspective. For this refer to the inforgram at the end of this section. All the communication between Drogon and the Master is well heard by the master’s son. In the IT world that means that Drogon is the Client App and all requets made by the app are visible to the user himself. Also, step 2 is a redirect link for the client, so, I could as well stretch the arrow from Drogon to the Master, but that seemed more confusing. Drogon here is both the client and the server side of the applicaiton.
The user ðĪŠ tries to access the resource ð°, gets kicked in the balls by the app ð and is sent to authorisation server ðĩâðŦ to confirm his or her identity.
After the checks are done by this authorisation center, the user get’s a link with a code ð generated by this authorisation server ðĩâðŦ.
The app ð then sends this code along with some info about itself along back to the authorisation server ðĩâðŦ. The authorisation server ðĩâðŦ generates a token ð° and sends it to the app ð via the user’s ðĪŠ browser, where it gets saved to the cookie or other storage, and is sent most likely in the Authorization header with a token keyword preceeding the token itself.
Happy END! (Although rather depends on the perpective….)
Basically, it translates to “Hey, this guy knows me, ask him and he will confirm I am a good fella”. While that doesn’t sound that reliable in our dragon scenario, its current implementation in IT world does. Essentially, it’s just another way to get some token. It’s just that in this case the token is not generated by the service that the client is trying to access but rather by some third-party authorised by both the client and the server.
There are 4 types of flow that can be used (from ChatGPT).
- Authorization Code Grant Flow: This is the most common and secure grant type. It involves the user being redirected to the service provider’s authorization server to grant permission. The user is then redirected back to the application with an authorization code, which the application exchanges for an access token. This grant type is suitable for web and mobile applications that have a server-side component to handle the exchange of the authorization code for the access token securely. This is what was roughly shown on the pictures above.
- Implicit Grant Flow: This grant type is a simplified version of the Authorization Code Grant Flow, designed for browser-based applications without a server-side component (e.g., Single Page Applications). Instead of receiving an authorization code, the application directly receives an access token after the user grants permission. However, this grant type is less secure than the Authorization Code Grant Flow because the access token is exposed in the browser URL and may be susceptible to token interception. If we try to apply this procedure to the scenario with Drogon, it means that there is no dove ð and the cake ð° is sent right away INSTEAD of the dove ð.
- Client Credentials Grant Flow: This grant type is used when an application needs to access resources it owns or manages on the service provider, rather than on behalf of a user. The application authenticates itself using its client credentials (client ID and client secret) and receives an access token directly. This grant type is suitable for machine-to-machine authentication and is often used in server-to-server scenarios where user involvement is not required. It if Drogon ð and the Master ðĩâðŦ are talking to each other without the little fella ðĪŠ.
- Password Grant Flow (Resource Owner Password Credentials): This grant type involves the user sharing their service provider credentials (username and password) directly with the application, which then uses these credentials to obtain an access token. This grant type is less secure and recommended only for trusted applications or legacy systems where other grant types are not feasible. It is not recommended for modern applications due to the security risks of sharing user credentials with third-party applications. In the example above, the master’s son ðĪŠ would have to show the passport and reveal the secret about the lady on the side ððŧ to Drogon ð directly. One can see how that’s not something you’d want. Although in the scenario I have described it looks like more the Master’s problem rather than the son’s (that’s why the scenario is not ðŊ% accurate, sorry ðĪ·ðŧââïļ). But imagine that lady on the side is something son’s not interested in revealing to anyone else either. Maybe he’s going into politics and the last thing he needs is a personal profile of ill repute.
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
SSO (Security Assertions Markup Language)
The idea is very close to OAuth, if you ask me: using a singe resource to login to multiple resources and that single resource NOT being the same password, god forbid ðĪðž!
Now, the highlevel overview is quite simple. Remember the last time that you bought an Oyster card or whatever analogous thing you have in your country (Troyka in Moscow or InstanbulKart in Instanbul)? It’s a card that can be used in subway, buses and even the river transport. When you buy a ticket from Identity Provider and pay for it. Then you provide this ticket to whatever service provider you are trying to use (river transport, a bus or subway). SSO is very similar to that. You don’t need separate tickets for each transport, you have one.
There are three parties involved here: IDP (identity provider), user and SP (service provider). Again, identity provider would be the master ðĩâðŦ since he’s the one who has LITERALLY provided his son with identity, service provider is obviously Drogon ð and the castle ð° he’s protecting. Lastly, the user is the son ðĪŠ.
Let’s imagine that the master has three castles and his son is able to get inside each of them. The second castle is protected by a bear ð§ļ and the third - by COVID-19 ðĶ . While Drogon needs to sniff his visitors, the bear relies on the sound of the footsteps ðĢ, and COVID-19 ðĶ checks the number and type of “weak points”. If only there was a way to get inside each one of them with just one set of credentials… ðĪ
What would happen is the son ðĪŠ comes to daddy ðĩâðŦ again and says, that he wants to have a card that would let him pass in any of these three castles. Daddy agrees, looks at his son very carefully, and gives him a note saying something like “My son who looks like this ðĪŠ can have acces to the following castles: ð°ðŊð”. Now, the son ðĪŠ comes to Drogon and gives him the card. Drogon is no fool, so he looks at the note and checks if there are any indications of tampering (letters fixed, part of the text erased etc). If there are non - Drogon will have to chew on something else.
I am adding this picture from Ethical Hackers Academy on LinkedIn because I think it’s a very good visualisation of the process.
SAML
It’s a protocol for SSO, XML-based.
OpenID
It’s just of the Identity providers. OpenID was developed by the OpenID Foundation, and its successor, OpenID Connect, is built on top of the OAuth 2.0 protocol, allowing for both authentication and authorization capabilities.