Learn Curl - Authentication, Cookies & Session

#Introduction

In episode 9, you took control of the network — proxies, DNS, and connections. Now we move to the next layer: who you are. Many endpoints won't answer until you prove your identity. In this episode, we'll dissect the authentication schemes most used in the real world — from simple ones like Basic to modern tokens — then close with cookie management for building complete login sessions.

An important understanding from the start: authentication answers "who are you?", while authorization answers "what are you allowed to do?". curl handles the former; the server decides the latter. Confusion between the two is the source of the often-mixed-up 401 (not authenticated) versus 403 (not allowed) errors.

#Basic Authentication: -u

The Basic scheme is the oldest and simplest. Credentials are sent as an Authorization header with the value Basic <base64-result> — in practice, you don't need to compute base64 manually because -u handles it:

curl -u budi:rahasia https://api.example.com/private/data

-u budi:rahasia sends the username and password together. Because base64 encoding is only an encoding, not encryption — anyone snooping on the traffic can decode it — Basic auth must be used with HTTPS. Without TLS, your credentials travel almost naked across the network.

#Digest: --digest

Digest was created to fix Basic's weakness. Instead of sending credentials, the client computes a hash from the combination of credentials, a nonce, and other parameters from the server:

curl --digest -u budi:rahasia https://api.example.com/private/data

Because what's sent is a hash, not raw credentials, Digest is safer than Basic against passive interception — although both should still go over HTTPS. Some servers (especially older ones) only accept Digest, so knowing when to use --digest saves you from repeated errors.

#NTLM and Negotiate

In Windows environments and corporate infrastructure, two other schemes appear: NTLM and Negotiate (Kerberos). NTLM is a typical Windows challenge-response protocol; Negotiate automatically picks the best scheme, usually Kerberos on a domain network.

curl --ntlm -u domain\\budi:rahasia https://intranet.example.com/data

curl --negotiate -u : https://intranet.example.com/data

Note two details: with NTLM, the username often includes the domain with a double backslash (domain\budi — needs escaping in the shell). With --negotiate, you can leave -u : to use credentials already present in the environment. These schemes are almost never used on public APIs, but are a must-know when working with internal corporate systems.

#Bearer Tokens: -H and --oauth2-bearer

The modern API era is token-based: the client requests a token from the auth server, then sends it in every request. The most common format is the Bearer token in the Authorization header:

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..." \
  https://api.example.com/me

Writing the header manually is easy, but there's a more concise option: --oauth2-bearer accepts the token without needing to write the Authorization: Bearer string every time:

curl --oauth2-bearer "eyJhbGciOiJIUzI1NiJ9..." \
  https://api.example.com/me

#Cookies and Sessions

Not all applications use tokens; many web apps still rely on cookies to track sessions. After login, the server sends a Set-Cookie cookie, and the browser (or curl) must send it back on every subsequent request. curl handles this with two simple options: -c to save cookies to a file, -b to read cookies from a file.

#Cookie Jar: -c and -b

curl -c cookies.txt --json '{"user":"budi","pass":"rahasia"}' \
  https://app.example.com/api/login

After the login above, all Set-Cookie cookies from the response are stored in the cookies.txt file (the cookie jar). The next request just reads the same file:

curl -b cookies.txt https://app.example.com/api/profile

Because curl doesn't store cookies between commands automatically — unlike browsers — the cookie jar is how you maintain a session across commands. This is the basis of the "login once, access many times" flow in scripts.

#Setting Cookies Manually: -b "name=value"

To send an already-known cookie without a file, -b also accepts name-value pairs directly:

curl -b "session=abc123; theme=dark" https://app.example.com/dashboard

Multiple cookies are separated by semicolons in one string. This pattern is fast for light testing, but for complex sessions the cookie jar remains the primary choice because it stores attributes like expiry and domain.

#Login Session Workflow

Let's assemble everything into a real flow: log in, save cookies, then access protected resources.

curl -c cookies.txt --json '{"user":"budi","pass":"rahasia"}' \
  https://app.example.com/api/login

curl -b cookies.txt https://app.example.com/api/profile | jq

curl -b cookies.txt -X POST https://app.example.com/api/logout

The flow above is an exact prototype of what a browser does when you log in: the first request proves identity, the response provides cookies, and subsequent requests carry the cookies as proof. By understanding this sequence, you can automate anything web-session-based — from downloading paid reports to checking internal dashboards.

#Closing

Episode 10 equips you with digital identity in curl: Basic auth via -u user:pass or an interactive prompt, Digest with --digest, NTLM and Negotiate for corporate environments, Bearer tokens via -H "Authorization: Bearer ..." or --oauth2-bearer, and session management with the -c and -b cookie jar.

The core thing to remember: authentication is proof of identity, cookies are the access card that accompanies you — and HTTPS is an absolute requirement for almost all the schemes above. The better you understand scheme selection, the fewer 401 dramas in your future.

In the next episode 11, we'll cover timeout, retry, and rate limiting — how to keep curl from hanging forever, how to withstand temporary failures, and how to limit transfer speed. See you!