WEBVTT 1 00:00:00.000 --> 00:00:01.470 In this lesson, 2 00:00:01.470 --> 00:00:05.610 we will learn about authentication and authorization. 3 00:00:05.610 --> 00:00:07.740 The process of authentication 4 00:00:07.740 --> 00:00:12.740 and authorization involves verifying a user's identity 5 00:00:12.840 --> 00:00:15.030 and determining their access rights 6 00:00:15.030 --> 00:00:18.150 to resources within a system. 7 00:00:18.150 --> 00:00:21.630 Authentication and authorization concepts 8 00:00:21.630 --> 00:00:24.000 include attestation, 9 00:00:24.000 --> 00:00:28.497 the use of the security assertion markup language, or SAML, 10 00:00:28.497 --> 00:00:33.390 OpenID, OAuth, and federation. 11 00:00:33.390 --> 00:00:37.410 Attestation is the process of verifying that a system 12 00:00:37.410 --> 00:00:40.770 or entity complies with certain policies 13 00:00:40.770 --> 00:00:45.637 or standards, often as part of the authentication process. 14 00:00:45.637 --> 00:00:48.720 The security assertion markup language, 15 00:00:48.720 --> 00:00:53.280 or SAML, is a standard for exchanging authentication 16 00:00:53.280 --> 00:00:56.790 and authorization data between parties. 17 00:00:56.790 --> 00:01:01.179 OpenID is an authentication protocol that allows users 18 00:01:01.179 --> 00:01:04.230 to log into multiple services 19 00:01:04.230 --> 00:01:07.200 using a single identity provider. 20 00:01:07.200 --> 00:01:09.486 An identity provider is a service 21 00:01:09.486 --> 00:01:12.435 that manages user identity information 22 00:01:12.435 --> 00:01:17.010 and asserts authentication to enable secure access 23 00:01:17.010 --> 00:01:20.340 to multiple applications or systems. 24 00:01:20.340 --> 00:01:24.240 Next, OAuth is an authorization framework 25 00:01:24.240 --> 00:01:27.030 that allows third party applications 26 00:01:27.030 --> 00:01:30.750 to access user data without passing their credentials 27 00:01:30.750 --> 00:01:32.760 to the third party. 28 00:01:32.760 --> 00:01:36.540 And finally, federation refers to the practice 29 00:01:36.540 --> 00:01:40.740 of asserting identities across multiple domains. 30 00:01:40.740 --> 00:01:43.320 Let's learn more about attestation, 31 00:01:43.320 --> 00:01:46.110 the security assertion markup language, 32 00:01:46.110 --> 00:01:50.040 OpenID, OAuth, and federation. 33 00:01:50.040 --> 00:01:52.920 First, we have attestation. 34 00:01:52.920 --> 00:01:57.360 Attestation is the process of verifying that a user, system, 35 00:01:57.360 --> 00:02:02.360 or device meets specific security standards and policies. 36 00:02:02.400 --> 00:02:06.360 It plays an important role in authentication by proving 37 00:02:06.360 --> 00:02:08.310 that the user or entity trying 38 00:02:08.310 --> 00:02:11.040 to access a resource is legitimate 39 00:02:11.040 --> 00:02:13.290 and has not been compromised. 40 00:02:13.290 --> 00:02:16.440 For example, in a secure workplace, 41 00:02:16.440 --> 00:02:20.790 attestation can be used to ensure that a user's credentials, 42 00:02:20.790 --> 00:02:24.900 such as a certificate or security token, are valid 43 00:02:24.900 --> 00:02:28.650 and comply with organizational security policies 44 00:02:28.650 --> 00:02:32.280 before granting access to sensitive information 45 00:02:32.280 --> 00:02:33.960 or a resource. 46 00:02:33.960 --> 00:02:36.390 This attestation process 47 00:02:36.390 --> 00:02:41.040 helps prevent unauthorized access by confirming the identity 48 00:02:41.040 --> 00:02:45.780 and authenticity of the user prior to granting resource 49 00:02:45.780 --> 00:02:47.610 or data access. 50 00:02:47.610 --> 00:02:50.700 Attestation often involves generating 51 00:02:50.700 --> 00:02:54.449 a unique digital signature or hash value 52 00:02:54.449 --> 00:02:57.780 that proves a user's credentials are genuine 53 00:02:57.780 --> 00:02:59.880 and have not been altered. 54 00:02:59.880 --> 00:03:03.840 This proof is then sent to a verifying party, 55 00:03:03.840 --> 00:03:06.390 such as an access control system, 56 00:03:06.390 --> 00:03:09.870 which checks that the user's credentials are valid 57 00:03:09.870 --> 00:03:13.950 and meet specific security policies, protocols, 58 00:03:13.950 --> 00:03:16.620 or compliance requirements established 59 00:03:16.620 --> 00:03:19.320 by an organization or system. 60 00:03:19.320 --> 00:03:23.460 So if the attestation process confirms 61 00:03:23.460 --> 00:03:28.200 that the user is legitimate, access to resource is granted. 62 00:03:28.200 --> 00:03:31.080 If not, access is denied. 63 00:03:31.080 --> 00:03:35.340 This ensures that only trusted users can interact 64 00:03:35.340 --> 00:03:38.220 with secure systems and data. 65 00:03:38.220 --> 00:03:42.240 In applications, attestation is widely used 66 00:03:42.240 --> 00:03:46.950 to verify the identity and security status of users 67 00:03:46.950 --> 00:03:50.760 in cloud services, remote access setups, 68 00:03:50.760 --> 00:03:53.400 and secure boot processes. 69 00:03:53.400 --> 00:03:57.600 By verifying users and their associated credentials, 70 00:03:57.600 --> 00:04:00.780 attestation helps protect sensitive data 71 00:04:00.780 --> 00:04:05.610 and resources enhancing overall security by ensuring 72 00:04:05.610 --> 00:04:08.610 that access is only granted to users 73 00:04:08.610 --> 00:04:12.090 who meet stringent security requirements. 74 00:04:12.090 --> 00:04:16.620 Second, we have the security assertion markup language 75 00:04:16.620 --> 00:04:18.150 or SAML. 76 00:04:18.150 --> 00:04:21.780 SAML is a standard that facilitates the exchange 77 00:04:21.780 --> 00:04:26.370 of authentication and authorization data between parties, 78 00:04:26.370 --> 00:04:29.400 typically between an identity provider 79 00:04:29.400 --> 00:04:31.020 and a service provider. 80 00:04:31.020 --> 00:04:34.770 SAML can allow users to authenticate once 81 00:04:34.770 --> 00:04:36.990 with an identity provider 82 00:04:36.990 --> 00:04:39.630 and then access multiple services 83 00:04:39.630 --> 00:04:42.510 without needing to log in again. 84 00:04:42.510 --> 00:04:46.230 This is known as single sign-on or SSO, 85 00:04:46.230 --> 00:04:49.200 which simplifies the user experience 86 00:04:49.200 --> 00:04:53.580 and enhances security by centralizing authentication. 87 00:04:53.580 --> 00:04:58.110 For example, consider a business where employees need access 88 00:04:58.110 --> 00:05:02.100 to various applications like email, file storage, 89 00:05:02.100 --> 00:05:06.510 and HR systems within the same organization. 90 00:05:06.510 --> 00:05:09.720 With SAML, employees log in just once 91 00:05:09.720 --> 00:05:12.660 to the company's identity provider. 92 00:05:12.660 --> 00:05:17.370 SAML is then used to securely pass their authentication data 93 00:05:17.370 --> 00:05:19.350 to other applications, 94 00:05:19.350 --> 00:05:23.217 allowing seamless access without additional logins. 95 00:05:23.217 --> 00:05:26.730 This approach reduces password fatigue 96 00:05:26.730 --> 00:05:29.820 and lowers the risk of security issues related 97 00:05:29.820 --> 00:05:32.580 to managing multiple passwords. 98 00:05:32.580 --> 00:05:35.370 SAML uses extensible markup language 99 00:05:35.370 --> 00:05:39.750 or XML-based tokens to communicate authentication 100 00:05:39.750 --> 00:05:42.420 and authorization information. 101 00:05:42.420 --> 00:05:45.480 SAML is also popular in environments 102 00:05:45.480 --> 00:05:48.996 that require secure cross-domain single sign-on, 103 00:05:48.996 --> 00:05:53.996 allowing organizations to maintain control over user access 104 00:05:54.030 --> 00:05:56.580 between domains and organizations 105 00:05:56.580 --> 00:05:59.700 through a centralized authentication management. 106 00:05:59.700 --> 00:06:02.683 Third, we have OpenID. 107 00:06:02.683 --> 00:06:07.683 OpenID is an authentication protocol that enables users 108 00:06:07.770 --> 00:06:11.970 to log into multiple services using a single set 109 00:06:11.970 --> 00:06:15.930 of credentials managed by an identity provider. 110 00:06:15.930 --> 00:06:20.310 This simplifies the login process by allowing users 111 00:06:20.310 --> 00:06:22.890 to maintain a single identity 112 00:06:22.890 --> 00:06:26.220 across multiple platforms and domains, 113 00:06:26.220 --> 00:06:29.790 reducing the need to remember multiple usernames 114 00:06:29.790 --> 00:06:31.680 and passwords. 115 00:06:31.680 --> 00:06:34.890 OpenID is commonly used by websites 116 00:06:34.890 --> 00:06:39.210 and applications to streamline user authentication 117 00:06:39.210 --> 00:06:41.370 and improve security. 118 00:06:41.370 --> 00:06:44.160 For example, when a user logs 119 00:06:44.160 --> 00:06:48.870 into different website domains using their Google account, 120 00:06:48.870 --> 00:06:51.630 they're likely using OpenID. 121 00:06:51.630 --> 00:06:56.490 In this situation, Google acts as the identity provider, 122 00:06:56.490 --> 00:06:59.100 verifying the user's credentials, 123 00:06:59.100 --> 00:07:02.040 and then communicating this authentication 124 00:07:02.040 --> 00:07:04.650 to other various websites. 125 00:07:04.650 --> 00:07:08.760 This allows users to access multiple services 126 00:07:08.760 --> 00:07:12.510 without creating separate accounts for each. 127 00:07:12.510 --> 00:07:16.260 So OpenID provides a consistent 128 00:07:16.260 --> 00:07:20.220 and standardized way to handle authentication, 129 00:07:20.220 --> 00:07:22.650 enhancing user experience 130 00:07:22.650 --> 00:07:26.820 and reducing the risk of weak or reused passwords. 131 00:07:26.820 --> 00:07:29.880 It also benefits service providers 132 00:07:29.880 --> 00:07:34.080 by outsourcing the complexity of user authentication 133 00:07:34.080 --> 00:07:37.020 to a trusted identity provider, 134 00:07:37.020 --> 00:07:41.280 allowing them to focus more on their core services. 135 00:07:41.280 --> 00:07:43.590 Fourth, we have OAuth. 136 00:07:43.590 --> 00:07:48.110 OAuth, which stands for Open Authorization is a framework 137 00:07:48.110 --> 00:07:50.970 that allows third party applications 138 00:07:50.970 --> 00:07:53.190 to access a user's data 139 00:07:53.190 --> 00:07:57.420 without directly handling the authentication process. 140 00:07:57.420 --> 00:07:59.040 In these scenarios, 141 00:07:59.040 --> 00:08:03.090 unlike the authentication process handled by OpenID, 142 00:08:03.090 --> 00:08:06.990 OAuth focuses on authorization, 143 00:08:06.990 --> 00:08:11.100 determining what data the third party is allowed to access, 144 00:08:11.100 --> 00:08:15.690 and what actions it can perform on behalf of the user. 145 00:08:15.690 --> 00:08:20.010 This separation keeps user credentials secure 146 00:08:20.010 --> 00:08:24.240 and limits the scope of what external applications can do. 147 00:08:24.240 --> 00:08:28.710 For example, when you connect your social media account 148 00:08:28.710 --> 00:08:32.340 to a third party application to share photos, 149 00:08:32.340 --> 00:08:35.220 OAuth allows that application 150 00:08:35.220 --> 00:08:39.420 to access specific data from your social media account 151 00:08:39.420 --> 00:08:42.900 without revealing your login credentials. 152 00:08:42.900 --> 00:08:47.310 So the third party application receives a token 153 00:08:47.310 --> 00:08:49.560 that grants it permission only 154 00:08:49.560 --> 00:08:52.470 to the data that you agreed to share, 155 00:08:52.470 --> 00:08:56.520 and this token can be revoked at any time, 156 00:08:56.520 --> 00:09:01.050 giving you control over what the application can access. 157 00:09:01.050 --> 00:09:05.460 Overall, OAuth works by issuing tokens instead 158 00:09:05.460 --> 00:09:09.630 of credentials, significantly reducing security risks 159 00:09:09.630 --> 00:09:11.790 associated with sharing passwords 160 00:09:11.790 --> 00:09:15.150 between services and providing a secure 161 00:09:15.150 --> 00:09:19.170 and flexible way to manage access permissions. 162 00:09:19.170 --> 00:09:23.370 Fifth and finally, we have federation. 163 00:09:23.370 --> 00:09:26.430 Federation refers to the practice of sharing 164 00:09:26.430 --> 00:09:31.170 and managing user identities across multiple domains 165 00:09:31.170 --> 00:09:35.130 or organizations allowing for seamless access 166 00:09:35.130 --> 00:09:39.660 to resources without requiring multiple logins. 167 00:09:39.660 --> 00:09:42.300 Federation enables organizations 168 00:09:42.300 --> 00:09:46.230 to trust each other's identity management systems, 169 00:09:46.230 --> 00:09:50.940 allowing users to access services in one domain based 170 00:09:50.940 --> 00:09:55.740 on authentication performed by another trusted domain. 171 00:09:55.740 --> 00:09:58.470 This simplifies access management 172 00:09:58.470 --> 00:10:03.470 and enhances user experience in multi-domain environments. 173 00:10:03.630 --> 00:10:08.610 For instance, a university system might use federation 174 00:10:08.610 --> 00:10:11.190 to allow students from one campus 175 00:10:11.190 --> 00:10:14.400 to access resources at another campus 176 00:10:14.400 --> 00:10:17.130 without needing separate credentials. 177 00:10:17.130 --> 00:10:18.690 Through federation, 178 00:10:18.690 --> 00:10:23.370 the student's home campus can authenticate their identity, 179 00:10:23.370 --> 00:10:27.390 and the second campus can trust this authentication 180 00:10:27.390 --> 00:10:30.570 and grant access to its resources. 181 00:10:30.570 --> 00:10:32.880 This allows for efficient 182 00:10:32.880 --> 00:10:37.440 and secure access without compromising the integrity 183 00:10:37.440 --> 00:10:40.890 of each domain's security policies. 184 00:10:40.890 --> 00:10:44.220 Federation often uses standards 185 00:10:44.220 --> 00:10:47.550 like SAML to exchange authentication 186 00:10:47.550 --> 00:10:52.020 and authorization data between identity providers 187 00:10:52.020 --> 00:10:54.150 and service providers. 188 00:10:54.150 --> 00:10:58.350 Federation is also widely used in businesses, 189 00:10:58.350 --> 00:11:00.330 educational institutions, 190 00:11:00.330 --> 00:11:04.440 and government agencies to streamline user access 191 00:11:04.440 --> 00:11:08.310 and maintain secure, scalable identity management 192 00:11:08.310 --> 00:11:10.770 across multiple systems. 193 00:11:10.770 --> 00:11:14.460 Now, let's consider a complex example 194 00:11:14.460 --> 00:11:17.610 that brings many of these concepts together. 195 00:11:17.610 --> 00:11:21.600 Imagine a university system where students need 196 00:11:21.600 --> 00:11:24.840 to access various online resources, 197 00:11:24.840 --> 00:11:28.830 such as the library database, the student portal, 198 00:11:28.830 --> 00:11:31.380 and third party educational tools 199 00:11:31.380 --> 00:11:33.690 like alerting management system. 200 00:11:33.690 --> 00:11:38.040 The university employs a federated identity management 201 00:11:38.040 --> 00:11:42.780 approach to streamline access across these services 202 00:11:42.780 --> 00:11:45.210 while maintaining security. 203 00:11:45.210 --> 00:11:49.541 In this setup, the security assertion markup language, 204 00:11:49.541 --> 00:11:54.541 OpenID, and OAuth work together to handle authentication 205 00:11:55.050 --> 00:11:57.630 and authorization efficiently. 206 00:11:57.630 --> 00:12:00.300 Here's how the process unfolds. 207 00:12:00.300 --> 00:12:04.440 When a student logs into the university's main portal, 208 00:12:04.440 --> 00:12:06.914 or SAML is the protocol used 209 00:12:06.914 --> 00:12:09.150 to authenticate the student 210 00:12:09.150 --> 00:12:12.420 via the university's identity provider, 211 00:12:12.420 --> 00:12:15.540 which manages the student's credentials. 212 00:12:15.540 --> 00:12:19.620 The identity provider verifies the student's username 213 00:12:19.620 --> 00:12:23.370 and password confirming their identity, 214 00:12:23.370 --> 00:12:25.980 but if the student prefers, 215 00:12:25.980 --> 00:12:30.480 they can log in using an external account such as Google. 216 00:12:30.480 --> 00:12:34.080 Leveraging OpenID for authentication. 217 00:12:34.080 --> 00:12:36.495 OpenID allows the student 218 00:12:36.495 --> 00:12:39.330 to use their existing Google credentials 219 00:12:39.330 --> 00:12:42.690 with Google acting as the identity provider 220 00:12:42.690 --> 00:12:45.150 for the university's resources. 221 00:12:45.150 --> 00:12:48.420 This single sign-on assertion capability 222 00:12:48.420 --> 00:12:52.950 within the university's domain simplifies the login process 223 00:12:52.950 --> 00:12:57.950 for the student enabling access across multiple services 224 00:12:58.050 --> 00:13:01.080 without reentering their credentials. 225 00:13:01.080 --> 00:13:03.990 Once authenticated, the student might want 226 00:13:03.990 --> 00:13:08.160 to use a third party educational tool that integrates 227 00:13:08.160 --> 00:13:10.800 with the university system, 228 00:13:10.800 --> 00:13:13.680 such as a note-taking application 229 00:13:13.680 --> 00:13:16.350 or an interactive learning platform. 230 00:13:16.350 --> 00:13:20.853 Here, OAuth manages the authorization process. 231 00:13:20.853 --> 00:13:24.150 So instead of the student sharing 232 00:13:24.150 --> 00:13:26.130 their university credentials 233 00:13:26.130 --> 00:13:30.840 with the third party application, OAuth issues a token 234 00:13:30.840 --> 00:13:34.200 that grants the application specific permissions, 235 00:13:34.200 --> 00:13:36.300 such as access to course data 236 00:13:36.300 --> 00:13:37.710 or reading lists 237 00:13:37.710 --> 00:13:42.510 without exposing the user's sensitive login details. 238 00:13:42.510 --> 00:13:47.510 This token-based system allows the third party application 239 00:13:47.520 --> 00:13:50.820 to access only the information it needs, 240 00:13:50.820 --> 00:13:53.910 enhancing security by limiting access 241 00:13:53.910 --> 00:13:58.230 and giving the student control over what data is shared. 242 00:13:58.230 --> 00:14:03.230 So this federated and SSO environment leverages 243 00:14:03.690 --> 00:14:07.500 the security assertion markup language, or SAML, 244 00:14:07.500 --> 00:14:09.930 OpenID, and OAuth 245 00:14:09.930 --> 00:14:14.220 to provide a secure, user-friendly experience, 246 00:14:14.220 --> 00:14:17.730 allowing seamless access to a broad range 247 00:14:17.730 --> 00:14:22.730 of resources while maintaining strict access controls. 248 00:14:22.920 --> 00:14:27.920 So remember, authentication and authorization are processes 249 00:14:29.040 --> 00:14:31.443 that verify a user's identity 250 00:14:31.443 --> 00:14:33.840 and determine their access rights 251 00:14:33.840 --> 00:14:36.720 to resources within a system. 252 00:14:36.720 --> 00:14:41.640 Key concepts in this process include attestation, 253 00:14:41.640 --> 00:14:45.270 security assertions markup language, or SAML, 254 00:14:45.270 --> 00:14:49.083 OpenID, OAuth, and federation. 255 00:14:49.083 --> 00:14:53.154 Attestation verifies that a user, system, 256 00:14:53.154 --> 00:14:57.449 or device meets specific security standards, 257 00:14:57.449 --> 00:15:01.080 ensuring the authenticity of the entity 258 00:15:01.080 --> 00:15:03.660 before granting access. 259 00:15:03.660 --> 00:15:08.040 SAML is a protocol that facilitates the secure exchange 260 00:15:08.040 --> 00:15:12.570 of authentication data between an identity provider 261 00:15:12.570 --> 00:15:17.280 and service providers allowing users to log in once 262 00:15:17.280 --> 00:15:20.160 and access multiple resources. 263 00:15:20.160 --> 00:15:24.829 OpenID is an authentication protocol that enables users 264 00:15:24.829 --> 00:15:28.290 to use a single set of credentials managed 265 00:15:28.290 --> 00:15:33.030 by an identity provider to log into multiple services. 266 00:15:33.030 --> 00:15:37.260 OAuth is a framework that handles authorization, 267 00:15:37.260 --> 00:15:41.520 allowing third party applications to access user data 268 00:15:41.520 --> 00:15:44.850 without directly handling authentication. 269 00:15:44.850 --> 00:15:49.080 This is done often by using tokens instead of passwords 270 00:15:49.080 --> 00:15:51.000 to manage permissions. 271 00:15:51.000 --> 00:15:55.320 Finally, federation refers to the practice of sharing 272 00:15:55.320 --> 00:15:59.850 and managing user identities across multiple domains 273 00:15:59.850 --> 00:16:01.590 or organizations, 274 00:16:01.590 --> 00:16:06.240 allowing users to access services across different systems 275 00:16:06.240 --> 00:16:09.603 with a single authenticated identity.