0:00
I noticed that once most developers hear
0:02
terms like API key, JWT, OAuth bearer
0:06
token, session authentication, OpenID
0:09
Connect, or single sign-on, they often
0:11
[music] assume they all mean the same
0:13
thing, but they don't. Some of these
0:15
describe how credentials are sent
0:17
[music] over HTTP, some describe how the
0:19
login state is managed, some are token
0:22
formats, and others are full identity
0:24
protocols. The easiest way to understand
0:27
authentication [music] is to walk
0:28
through how these methods evolved over
0:30
time. Before I continue, there's so much
0:32
I can't share on YouTube, whether it's
0:35
because of platform rules or because
0:37
some skills need deeper hands-on
0:39
explanations. Many of my videos got
0:41
>> and that's why I created a PolicyPoint
0:44
learning community for you, a place
0:46
where I can share everything. [music]
0:48
When you join, you're not just getting
0:49
another course, you're getting access to
0:52
complete ethical hacking guides, the
0:54
tools and techniques [music] I wish
0:56
someone had handed me when I was
0:57
starting out. And here's the kicker.
1:00
This is the stuff I don't teach on here.
1:02
No watered-down content, no clickbait,
1:05
just raw, actionable knowledge. On top
1:08
of that, you'll join an exclusive
1:10
community on Discord. I pinned the link
1:12
in the comment section below, but it's
1:14
not for everyone. The link is only
1:16
available for those who are serious
1:18
about the journey. Now, let's begin with
1:20
one of the earliest approaches to
1:21
[music] basic authentication. Basic
1:24
authentication is one of the simplest
1:26
ways to authenticate [music]
1:27
a request. The client sends a username
1:30
and password with every HTTP request
1:33
using the authorization header. The
1:35
credentials are encoded using [music]
1:38
and attached to the request. Because
1:41
Base64 is just encoding and not
1:43
encryption, anyone intercepting the
1:45
request could decode the credentials if
1:49
is not used. This simplicity made basic
1:53
authentication popular in early APIs and
1:56
internal systems, but today it's rarely
1:59
used in production environments because
2:01
repeatedly sending credentials is risky.
2:03
To improve on that idea, digest [music]
2:06
authentication was introduced. Digest
2:08
authentication works using a
2:10
challenge-response mechanism. Instead of
2:12
sending [music] the password directly,
2:14
the server first sends a challenge to
2:16
the client. The client then generates a
2:18
hashed response using the password and
2:21
the challenge value. The server verifies
2:23
that hash instead of checking the raw
2:25
password. This prevents the password
2:27
from being transmitted in plain [music]
2:29
form. While it is more secure than basic
2:32
authentication, it is also more complex
2:35
and not widely used in modern systems
2:38
[music] because newer token-based
2:40
approaches are easier to scale. As web
2:42
applications became more common, a
2:45
different approach emerged. Session
2:47
authentication Session authentication is
2:50
the traditional login mechanism used in
2:52
many websites. [music]
2:53
When a user logs in successfully, the
2:56
server creates a session that represents
2:58
the authenticated user. The server
3:00
stores that session and sends a session
3:02
ID to the browser, usually through a
3:05
cookie. On every subsequent request, the
3:07
browser [music] automatically sends that
3:09
cookie back to the server. The server
3:11
reads the session ID and knows which
3:14
user's making the request. [music] This
3:16
approach works well for server-rendered
3:18
web applications, but it requires the
3:20
server to store session data, which
3:22
becomes harder to manage when systems
3:25
scale across multiple servers. [music]
3:27
To avoid storing login state on the
3:29
server, modern systems often use tokens
3:33
instead. One of the simplest token
3:35
mechanisms is the API key. An API key is
3:39
a unique identifier assigned to a
3:41
developer or application. The client
3:44
includes this key with each request, so
3:46
the server can identify which
3:48
application is calling the API. API keys
3:51
are commonly used for public APIs
3:53
[music] such as maps, weather services,
3:55
or payment integrations. However, API
3:58
keys usually identify the application
4:01
rather than the individual user, so
4:03
they're often combined with other
4:04
security mechanisms. As [music] APIs and
4:07
microservices became more common,
4:09
another concept became widely [music]
4:11
used, bearer tokens. Bearer
4:13
authentication means the client sends a
4:15
token in the authorization header with
4:18
the format authorization colon bearer.
4:21
The word bearer simply means that
4:23
whoever holds the token is allowed to
4:25
use it. The server verifies the token
4:27
and allows access to the requested
4:29
resource. This method is widely used in
4:33
because the server does not need to
4:35
store session state. However, bearer
4:38
tokens must be protected carefully
4:40
because anyone who obtains a token can
4:42
[music] impersonate the user until the
4:44
token expires. Many bearer tokens today
4:47
are implemented using JSON web tokens,
4:50
>> commonly called JWT. JWT is not a
4:54
protocol, it is simply a token format. A
4:56
JWT contains information about the user
4:59
in a structured JSON payload. [music]
5:02
The token is digitally signed by the
5:03
server, which ensures that the data
5:05
inside the token has not been modified.
5:07
Because the token contains the
5:09
information needed to identify the user,
5:11
the server can verify requests without
5:13
querying a database every time. This
5:16
makes JWT very useful in distributed
5:19
systems and microservice architectures.
5:22
When tokens are used in real systems,
5:24
they usually [music] come in two forms,
5:26
access tokens and refresh tokens. An
5:29
access token is used to access protected
5:31
APIs. These tokens are intentionally
5:34
short-lived, often lasting only minutes
5:37
or hours. [music] If an access token is
5:39
compromised, the attacker only has a
5:42
limited window of time to use it. A
5:44
refresh token is different. It is
5:46
longer-lived and is used to request a
5:48
new access token when the old one
5:51
expires. This allows applications to
5:53
maintain a user's login session without
5:56
forcing them to repeatedly enter their
5:58
credentials. As applications start
6:00
integrating with other platforms,
6:02
another technology became essential.
6:07
OAuth is an authorization framework
6:10
designed to allow applications [music]
6:12
to access resources on behalf of a user
6:15
without ever seeing the user's password.
6:17
[music] For example, when an application
6:19
asks for permission to access your
6:21
Google Drive or GitHub account, OAuth is
6:25
typically used. The user authenticates
6:28
with the external provider and the
6:30
application receives an access token
6:32
that grants limited permissions. OAuth
6:35
focuses on authorization, deciding what
6:38
an application is allowed to access.
6:40
However, OAuth alone does not provide a
6:42
standardized way to verify a user's
6:44
identity. That's why OpenID Connect,
6:47
often called OIDC, was introduced.
6:50
OpenID Connect builds on top of OAuth
6:53
2.0 and adds an identity layer. It
6:56
introduces something called an ID token,
6:59
which contains verified information
7:01
about the user. This allows applications
7:03
to confirm the user's identity without
7:06
managing passwords themselves. Modern
7:08
login systems, such as sign in with
7:11
Google or sign in with Microsoft, are
7:13
typically implemented [music] using
7:15
OpenID Connect. Finally, many
7:17
organizations implement single sign on
7:20
or SSO. Single sign on is not a specific
7:23
protocol, but a user experience. It
7:26
means a user signs in once and gains
7:28
access to multiple applications without
7:31
logging in again. For example, when you
7:33
log into your company account and
7:35
automatically gain access to email
7:38
dashboards and internal tools, that is
7:40
so behind the scenes identity protocols
7:43
such as OpenID Connect or SAML make this
7:46
possible. When you look at all these
7:48
concepts together, authentication starts
7:50
to make much more sense. Early systems
7:53
relied on simple credential-based
7:54
methods like basic authentication.
7:57
[music] Web applications introduced
7:59
sessions to manage login state. Modern
8:02
AP is shifted toward token-based
8:04
authentication. OAuth enabled secure
8:07
access between applications. OpenID
8:10
Connect [music] added identity
8:11
verification and so created a seamless
8:14
login experience across multiple
8:16
systems. Understanding how these
8:18
concepts fit together [music] allows
8:20
developers to design authentication
8:22
systems that are secure, scalable, and
8:25
easy for users to interact with.
