1
00:00:00,730 --> 00:00:03,720
Authentication is only
one part of the story.

2
00:00:03,720 --> 00:00:08,410
You also need to be sure your users
are allowed to perform certain actions.

3
00:00:08,410 --> 00:00:10,740
This is known as authorization, and

4
00:00:10,740 --> 00:00:13,470
it's mainly about managing permissions for
users.

5
00:00:14,470 --> 00:00:17,380
Why do you need to authorize
a user by specifying

6
00:00:17,380 --> 00:00:18,950
every action they are allowed to perform?

7
00:00:20,130 --> 00:00:24,860
In this simple case, you could give a user
the ability to access your admin panel and

8
00:00:24,860 --> 00:00:26,460
steal credentials.

9
00:00:26,460 --> 00:00:27,630
Even worse,

10
00:00:27,630 --> 00:00:32,540
a user could gain access to the underlying
servers on which you run your software.

11
00:00:32,540 --> 00:00:37,430
This would allow them to steal even more
data or use the servers in a botnet.

12
00:00:37,430 --> 00:00:39,970
The malicious possibilities are endless,
and

13
00:00:39,970 --> 00:00:45,030
it's your job as an informed developer
to protect your users and your services.

14
00:00:46,330 --> 00:00:49,650
When authorizing users to perform actions,
you should

15
00:00:49,650 --> 00:00:54,890
always validate your users' actions,
both on the client and on the server.

16
00:00:54,890 --> 00:00:58,600
Validating actions on the client
reduces low hanging fruit for

17
00:00:58,600 --> 00:01:00,520
less motivated attackers.

18
00:01:00,520 --> 00:01:05,520
However, client-sided code is much
more vulnerable to malicious attacks.

19
00:01:05,520 --> 00:01:08,610
You should always validate
on the server as well.

20
00:01:08,610 --> 00:01:12,050
When the action is validated on
the server, the malicious user

21
00:01:12,050 --> 00:01:17,290
is required to have access to the code
on a web server in some other location.

22
00:01:17,290 --> 00:01:20,990
Although there may be bugs in
the code which would allow access,

23
00:01:20,990 --> 00:01:24,750
server side code is
typically easier to protect.

24
00:01:24,750 --> 00:01:28,850
If you only validate in one place,
always validate on the server.

25
00:01:30,060 --> 00:01:33,170
Depending on the language in which
your application is written,

26
00:01:33,170 --> 00:01:35,360
there are plenty of existing libraries and

27
00:01:35,360 --> 00:01:39,380
frameworks that provide some
sort of built-in authorization.

28
00:01:39,380 --> 00:01:43,870
For example, in JavaScript, there
are libraries to provide permissions and

29
00:01:43,870 --> 00:01:46,300
access controls to objects.

30
00:01:46,300 --> 00:01:50,860
Additionally, you can write custom
business logic to prevent certain users

31
00:01:50,860 --> 00:01:54,740
from performing certain actions
by checking their identity

32
00:01:54,740 --> 00:01:56,550
against the action.

33
00:01:56,550 --> 00:01:59,150
Finally, for more advanced requirements,

34
00:01:59,150 --> 00:02:03,520
you can put systems in place that
detect unusual user activity.

35
00:02:03,520 --> 00:02:09,030
As with login activity, by monitoring
the number of actions and spacing between

36
00:02:09,030 --> 00:02:15,400
actions, policies can be enforced that
will limit or block certain actions.

37
00:02:15,400 --> 00:02:19,360
Now, you should have a good idea
of the types of tools to look for

38
00:02:19,360 --> 00:02:21,600
when building your own application.

39
00:02:21,600 --> 00:02:22,910
Check out the teacher's notes for

40
00:02:22,910 --> 00:02:27,900
more resources around TLS,
authentication, and authorization.

41
00:02:27,900 --> 00:02:28,970
In the next stage,

42
00:02:28,970 --> 00:02:32,950
we're going to look at maintaining the
security of an application in production.