Learn · Backend & APIs
Authentication & Auth
Every real API needs to know who is calling and what they’re allowed to do. Get this wrong and anyone can read anyone’s data. Here’s how it actually works.
Before we start
- Authentication vs Authorization
- API keys, sessions, and JWT — how each works
- How a JWT lets a server trust you without a database lookup
- The security basics you must never skip
- Explain the difference between authn and authz
- Describe the JWT login flow out loud
- Say why passwords are hashed and keys are secret
Why you’re learning it: auth secures every API you’ll build, it’s core to Spring Security, and your Ayris merchant API keys are exactly this. ⏱️ ~25 min. Do APIs & REST first.
Two different questions
Who are you? Proving identity — logging in with a password, an API key, a token.
What are you allowed to do? Even known users can’t do everything — an admin can delete, a normal user can’t.
The three common methods
- API keys — a long secret string sent with each request. Simple, used for server-to-server. Your Ayris merchants authenticate with keys like this. Store them hashed, never plain.
- Sessions + cookies — you log in, the server remembers you and gives your browser a cookie it sends back each time. Classic for websites.
- JWT (JSON Web Token) — a signed token that carries your identity, so the server can trust it without looking anything up. The modern default for APIs.
How a JWT works — the wristband
Think of a concert wristband. At the gate they check your ID once and give you a wristband. After that, you flash the wristband to get anywhere — nobody re-checks your ID, because the wristband itself is proof (it’s hard to fake). A JWT is that wristband:
- You log in with username + password.
- The server checks them and returns a signed token (signed with a secret only the server knows).
- Your app sends that token in the header of every future request.
- The server verifies the signature — if it’s valid, it trusts you, no database lookup needed.
That “no lookup” is why JWTs scale well — the token is self-proving.
Security basics — never skip these
- Always HTTPS. Tokens and passwords over plain HTTP can be stolen in transit.
- Never store plain passwords. Store a hash (bcrypt) — even you shouldn’t be able to read them.
- Keep secrets secret. API keys and signing secrets never go in code you commit or in the frontend.
- Tokens expire. Short lifetimes limit the damage if one leaks.
Where you’ll use it — real life
Each merchant authenticates to the payment API with a hashed key — you’ve seen this.
The JWT filter-chain is a core Spring Boot skill — and a roadmap topic.
Staying logged in on an app is a token being sent on each request.
“Only admins can refund” is authorization in action.
Out loud: “What’s the difference between authentication and authorization, and how does a JWT let a server trust me without a lookup?” Then log it in your Journal.
Back to your Siemens roadmap →