ELI5: HTTP Authentication
Basically there are 3 types: Basic Authentication, Bearer Authentication and Cookie Authentication. I will give a super brief explanation of them which can serve as a quick-remembering-guide for example. Besides that, I mention some connected topics to keep in mind without going into more detail and I have a quick code snippet as well. Basic Authentication The simplest and oldest type - but it's insecure. So do not use it, just know about it. It's been in HTTP since version 1 and simply includes the credentials in the request: Authorization: Basic As you see, we set the HTTP header Authorization to the string username:password, encode it with base64 and prefix Basic. The server then decodes the value, that is, remove Basic and decode base64, and then checks if the credentials are correct. That's all. This is obviously insecure, even with HTTPS. If an attacker manages to 'crack' just one request, you're done. Still, we need HTTPS when using Basic Authentication (eg. to protect against eaves dropping attacks). Small note: Basic Auth is also vulnerable to CSRF since the browser caches the credentials and sends them along subsequent requests automatically. Bearer Authentication Bearer authentication relies on security tokens, often called bearer tokens. The idea behind the naming: the one bearing this token is allowed access. Authorization: Bearer Here we set the HTTP header Authorization to the token and prefix it with Bearer. The token usually is either a JWT (JSON Web Token) or a session token. Both have advantages and disadvantages - I wrote a separate article about this. Either way, if an attacker 'cracks' a request, he just has the token. While that is bad, usually the token expires after a while, rendering is useless. And, normally, tokens can be revoked if we figure out there was an attack. We need HTTPS with Bearer Authentication (eg. to protect against eaves dropping attacks). Cookie Authentication With cookie authentication we leverage cookies to authenticate the client. Upon successful login, the server responds with a Set-Cookie header containing a cookie name, value, and metadata like expiry time. For example: Set-Cookie: JSESSIONID=abcde12345; Path=/ Then the client must include this cookie in subsequent requests via the Cookie HTTP header: Cookie: JSESSIONID=abcde12345 The cookie usually is a token, again, usually a JWT or a session token. We need to use HTTPS here. Which one to use? Not Basic Authentication!
Basically there are 3 types: Basic Authentication, Bearer Authentication and Cookie Authentication. I will give a super brief explanation of them which can serve as a quick-remembering-guide for example. Besides that, I mention some connected topics to keep in mind without going into more detail and I have a quick code snippet as well.
Basic Authentication
The simplest and oldest type - but it's insecure. So do not use it, just know about it.
It's been in HTTP since version 1 and simply includes the credentials in the request:
Authorization: Basic
As you see, we set the HTTP header Authorization to the string username:password, encode it with base64 and prefix Basic. The server then decodes the value, that is, remove Basic and decode base64, and then checks if the credentials are correct. That's all.
This is obviously insecure, even with HTTPS. If an attacker manages to 'crack' just one request, you're done.
Still, we need HTTPS when using Basic Authentication (eg. to protect against eaves dropping attacks). Small note: Basic Auth is also vulnerable to CSRF since the browser caches the credentials and sends them along subsequent requests automatically.
Bearer Authentication
Bearer authentication relies on security tokens, often called bearer tokens. The idea behind the naming: the one bearing this token is allowed access.
Authorization: Bearer
Here we set the HTTP header Authorization to the token and prefix it with Bearer.
The token usually is either a JWT (JSON Web Token) or a session token. Both have advantages and disadvantages - I wrote a separate article about this.
Either way, if an attacker 'cracks' a request, he just has the token. While that is bad, usually the token expires after a while, rendering is useless. And, normally, tokens can be revoked if we figure out there was an attack.
We need HTTPS with Bearer Authentication (eg. to protect against eaves dropping attacks).
Cookie Authentication
With cookie authentication we leverage cookies to authenticate the client. Upon successful login, the server responds with a Set-Cookie header containing a cookie name, value, and metadata like expiry time. For example:
Set-Cookie: JSESSIONID=abcde12345; Path=/
Then the client must include this cookie in subsequent requests via the Cookie HTTP header:
Cookie: JSESSIONID=abcde12345
The cookie usually is a token, again, usually a JWT or a session token.
We need to use HTTPS here.
Which one to use?
Not Basic Authentication!
