1 00:00:06,700 --> 00:00:08,010 - [Instructor] In this lesson you will learn 2 00:00:08,010 --> 00:00:11,400 the different authentication schemes in web applications. 3 00:00:11,400 --> 00:00:14,920 So let's start by going over what is authentication 4 00:00:14,920 --> 00:00:17,450 and what is session management. 5 00:00:17,450 --> 00:00:20,730 Authentication is the process of verifying 6 00:00:20,730 --> 00:00:24,250 that whether it's an individual an entity or website 7 00:00:24,250 --> 00:00:27,420 is whoever actually is claiming to be right. 8 00:00:27,420 --> 00:00:31,900 So, authentication is in the context of a web application 9 00:00:31,900 --> 00:00:35,480 is commonly performed by submitting a username 10 00:00:35,480 --> 00:00:37,797 or an identifier, you know an ID 11 00:00:37,797 --> 00:00:41,520 and one or more items of private information like a, 12 00:00:41,520 --> 00:00:45,430 you know, password, some key, some token, 13 00:00:45,430 --> 00:00:48,250 some pressure key and so on. 14 00:00:48,250 --> 00:00:51,830 Now, session management is how a server maintains the state 15 00:00:51,830 --> 00:00:54,780 of an entity that is actually interacting with. 16 00:00:54,780 --> 00:00:56,730 This is required for a server 17 00:00:56,730 --> 00:01:01,730 to remember how to react to subsequent request. 18 00:01:01,780 --> 00:01:04,100 Sessions are maintained on the server by default 19 00:01:04,100 --> 00:01:06,910 with an identifier, with a session identifier. 20 00:01:06,910 --> 00:01:10,770 And this session ID is actually passed back and forth 21 00:01:10,770 --> 00:01:13,260 between the server and the client 22 00:01:13,260 --> 00:01:15,280 when transmitting or receiving a request, right. 23 00:01:15,280 --> 00:01:17,610 So session should be unique. 24 00:01:17,610 --> 00:01:19,380 Of course, we know per user. 25 00:01:19,380 --> 00:01:21,410 And also they should be computationally 26 00:01:21,410 --> 00:01:23,520 very difficult to predict. 27 00:01:23,520 --> 00:01:28,520 Now what web application scheme is a method or a recipe 28 00:01:28,660 --> 00:01:31,350 to pass those credentials from a user 29 00:01:31,350 --> 00:01:33,176 authenticating to a system, right. 30 00:01:33,176 --> 00:01:36,680 So from the user to the actual authenticating system. 31 00:01:36,680 --> 00:01:39,750 Now these schemes vary in their security and complexity. 32 00:01:39,750 --> 00:01:42,470 Some of it can only handle authentication 33 00:01:42,470 --> 00:01:43,860 and other ones can actually handle 34 00:01:43,860 --> 00:01:47,240 both authentication and authorization. 35 00:01:47,240 --> 00:01:50,080 Now, SSL or Secure Socket Layer 36 00:01:50,080 --> 00:01:52,580 or TLS, Transport Layer Security 37 00:01:52,580 --> 00:01:55,260 is typically used to ensure confidentiality 38 00:01:55,260 --> 00:01:58,150 and that's actually a required prerequisite 39 00:01:58,150 --> 00:02:02,680 for a lot of the authentication schemes to rely upon, right? 40 00:02:02,680 --> 00:02:05,420 So, at the end of the day, nowadays, 41 00:02:05,420 --> 00:02:08,410 all modern applications should be actually using TLS 42 00:02:08,410 --> 00:02:09,960 and a strong version of TLS. 43 00:02:09,960 --> 00:02:13,090 And we're gonna go into that later in the course. 44 00:02:13,090 --> 00:02:15,700 Now, the following are some of the most common types 45 00:02:15,700 --> 00:02:18,020 of web applications authentication schemes. 46 00:02:18,020 --> 00:02:20,843 So we have TLS and, you know, of course, SSL. 47 00:02:21,830 --> 00:02:26,160 And that is not only doing the authentication of the server, 48 00:02:26,160 --> 00:02:27,470 but mutual authentication. 49 00:02:27,470 --> 00:02:28,670 So that means authentication, 50 00:02:28,670 --> 00:02:30,100 client based authentication as well. 51 00:02:30,100 --> 00:02:31,840 And we're gonna cover that in a few. 52 00:02:31,840 --> 00:02:34,610 Now, HTTP basic auth, is another one. 53 00:02:34,610 --> 00:02:37,580 HTTP form based authentication is another one. 54 00:02:37,580 --> 00:02:41,586 DAA, LTPA or Lightweight Third-party Authentication, 55 00:02:41,586 --> 00:02:46,310 Oauth 2, OpenID, OpenID Connect and SAML. 56 00:02:46,310 --> 00:02:48,180 Right, so those are the most 57 00:02:48,180 --> 00:02:50,290 typical authentication schemes out there. 58 00:02:50,290 --> 00:02:51,680 So let's actually start with TLS. 59 00:02:51,680 --> 00:02:53,240 Right so TLS, a lot of people actually 60 00:02:53,240 --> 00:02:55,620 refer to is as SSL, right support. 61 00:02:55,620 --> 00:02:59,250 I do know there is modern versions of TLS, 62 00:02:59,250 --> 00:03:01,280 so 1.3 and above, 63 00:03:01,280 --> 00:03:03,440 is actually the central concept 64 00:03:03,440 --> 00:03:04,860 of, you know, protecting it out 65 00:03:04,860 --> 00:03:06,230 and authentication schemes, right. 66 00:03:06,230 --> 00:03:09,610 So the central concept is in TLS 67 00:03:09,610 --> 00:03:11,000 is actually the digital certificate 68 00:03:11,000 --> 00:03:15,290 and how they actually form a chain of trust. 69 00:03:15,290 --> 00:03:18,650 Now a digital or a public key certificate 70 00:03:18,650 --> 00:03:21,950 is an electronic document that is actually pub, 71 00:03:21,950 --> 00:03:26,540 approving or proving rather, the ownership of a public key. 72 00:03:26,540 --> 00:03:29,617 The certificate contains details about the key 73 00:03:29,617 --> 00:03:33,370 and the owner information and the digital signature 74 00:03:33,370 --> 00:03:35,200 of a certificate authority, 75 00:03:35,200 --> 00:03:37,940 who vouches for all the different contents, right. 76 00:03:37,940 --> 00:03:41,610 So, now the digital certificates and certificate authorities 77 00:03:41,610 --> 00:03:45,480 or CA's are central to public key infrastructure. 78 00:03:45,480 --> 00:03:47,970 Right, now, every web client 79 00:03:47,970 --> 00:03:50,970 has a default collection of certificates 80 00:03:50,970 --> 00:03:53,310 from a major certificate authority 81 00:03:53,310 --> 00:03:56,520 so your browser will have a list 82 00:03:56,520 --> 00:04:00,731 of a collection of trusted certificate authorities. 83 00:04:00,731 --> 00:04:03,710 That, are very popular there, right. 84 00:04:03,710 --> 00:04:05,390 Now each certificate is actually signed 85 00:04:05,390 --> 00:04:07,310 by a single authority and in turn, 86 00:04:07,310 --> 00:04:09,700 the certificate of the signer 87 00:04:09,700 --> 00:04:12,200 is actually signed by another authority, 88 00:04:12,200 --> 00:04:15,880 each becoming white, more widely accepted. 89 00:04:15,880 --> 00:04:20,110 Then finally the root certificate of the chain is self sign. 90 00:04:20,110 --> 00:04:21,600 And it's widely distributed. 91 00:04:21,600 --> 00:04:24,370 This root certificate is actually the anchor 92 00:04:24,370 --> 00:04:27,100 of the trust in that PKR environment 93 00:04:27,100 --> 00:04:29,720 is the public key infrastructure environment. 94 00:04:29,720 --> 00:04:30,810 And that's actually used 95 00:04:30,810 --> 00:04:34,050 to validate the entire certification tree, right. 96 00:04:34,050 --> 00:04:36,030 Now, any certificate can be trusted 97 00:04:36,030 --> 00:04:40,600 if it has been signed by a CA or certificate authority. 98 00:04:40,600 --> 00:04:44,750 Now by far, the most common use of digital certificates 99 00:04:44,750 --> 00:04:49,750 is establishing an SSL or TLS base channel of communication. 100 00:04:51,610 --> 00:04:54,950 Now SSL authentication can take two forms. 101 00:04:54,950 --> 00:04:57,830 Simple and mutual, but they also 102 00:04:57,830 --> 00:05:01,610 people refer them as the one-way or two-Way authentication. 103 00:05:01,610 --> 00:05:03,120 In one way authentication usually 104 00:05:03,120 --> 00:05:05,710 is whenever an HTTPS connection, 105 00:05:05,710 --> 00:05:09,300 right from your browser to a secure server 106 00:05:09,300 --> 00:05:10,300 is established, right? 107 00:05:10,300 --> 00:05:11,360 So in that case, actually, 108 00:05:11,360 --> 00:05:15,530 there's a one way SSL authentication, if you will, right? 109 00:05:15,530 --> 00:05:17,590 Because actually you're, the client 110 00:05:17,590 --> 00:05:22,440 is verifying that the data Certificate of the server. 111 00:05:22,440 --> 00:05:25,670 Now, if the certificate of the server is not found, 112 00:05:25,670 --> 00:05:26,930 but the signed certificate 113 00:05:26,930 --> 00:05:28,990 that the client actually does trust is found 114 00:05:28,990 --> 00:05:31,670 then the client, she also trust the server. 115 00:05:31,670 --> 00:05:34,820 You know, that's what we call the chain of trust. 116 00:05:34,820 --> 00:05:36,940 Now, in mutual authentication, 117 00:05:36,940 --> 00:05:38,930 everything that occurred in the first 118 00:05:38,930 --> 00:05:39,910 you know, the one way, 119 00:05:39,910 --> 00:05:41,760 you know, interaction still will happen, right? 120 00:05:41,760 --> 00:05:45,410 So the, those nine messages are exchanged, 121 00:05:45,410 --> 00:05:49,490 but they'll, also the server request the client, 122 00:05:49,490 --> 00:05:50,323 to present a certificate 123 00:05:50,323 --> 00:05:52,610 and to actually check it's sound collections 124 00:05:52,610 --> 00:05:55,420 of trusted certificates to determine if it actually 125 00:05:55,420 --> 00:05:56,760 can trust us the client. 126 00:05:56,760 --> 00:05:59,823 So that's the concept of mutual authentication, right? 127 00:06:00,780 --> 00:06:02,690 Now there's another method, 128 00:06:02,690 --> 00:06:07,690 if you will, called TSRP, or TLS, secure remote password, 129 00:06:08,090 --> 00:06:09,510 it was actually introduced as a means 130 00:06:09,510 --> 00:06:10,720 to provide a password based 131 00:06:10,720 --> 00:06:12,500 client authentication to a server 132 00:06:12,500 --> 00:06:14,100 without the need of certificate. 133 00:06:14,100 --> 00:06:16,150 It actually addresses the usability issues, 134 00:06:16,150 --> 00:06:18,362 you know, managing certificate clients, 135 00:06:18,362 --> 00:06:20,550 and you know, you don't have to actually worry about the, 136 00:06:20,550 --> 00:06:22,990 the dual mutual authentication of certificates 137 00:06:22,990 --> 00:06:24,770 and how they actually are, 138 00:06:24,770 --> 00:06:27,850 are exchanged or maintained and everything else. 139 00:06:27,850 --> 00:06:32,690 But typically, technically TLS or SRP, 140 00:06:32,690 --> 00:06:35,490 was never widely adopted. 141 00:06:35,490 --> 00:06:38,280 And it actually suffers from being you know, accepted. 142 00:06:38,280 --> 00:06:41,690 So you barely actually use this nowadays. 143 00:06:41,690 --> 00:06:44,370 But you know, just be aware that there's another method 144 00:06:44,370 --> 00:06:46,510 called TLS, secure remote password. 145 00:06:46,510 --> 00:06:48,770 So whenever you actually are doing your assessments 146 00:06:48,770 --> 00:06:49,980 and your pen testing, 147 00:06:49,980 --> 00:06:52,150 you may encounter some of these, right. 148 00:06:52,150 --> 00:06:54,900 Now going to the traditional authentication method. 149 00:06:54,900 --> 00:06:57,450 You also have the basic HTTP authentication, right. 150 00:06:57,450 --> 00:06:58,970 So that's the integration actually, 151 00:06:58,970 --> 00:07:02,040 you see in pop up messages from your browser. 152 00:07:02,040 --> 00:07:04,960 There, hopefully they're barely used nowadays. 153 00:07:04,960 --> 00:07:07,470 And they have no cookies, no handshakes 154 00:07:07,470 --> 00:07:09,750 it's really basic authentication. 155 00:07:09,750 --> 00:07:12,450 It actually uses a dedicated HTTP header 156 00:07:12,450 --> 00:07:15,350 to actually communicate the encoded username and password 157 00:07:15,350 --> 00:07:18,000 on every request that you use authentication. 158 00:07:18,000 --> 00:07:19,836 So that requires the client. 159 00:07:19,836 --> 00:07:23,530 So your browser, to actually cache the credentials 160 00:07:23,530 --> 00:07:24,920 for a period of time. 161 00:07:24,920 --> 00:07:26,650 Otherwise, the user will actually be prompted 162 00:07:26,650 --> 00:07:28,690 to log in repeatedly, you know, every time. 163 00:07:28,690 --> 00:07:30,670 Now since the credentials 164 00:07:30,670 --> 00:07:32,860 are basically transmitted in the clear, 165 00:07:32,860 --> 00:07:35,170 that's when you actually have to pair up 166 00:07:35,170 --> 00:07:37,120 with SSL and TLS, right. 167 00:07:37,120 --> 00:07:38,950 Now, it is simple to use 168 00:07:38,950 --> 00:07:40,090 as simple to understand, 169 00:07:40,090 --> 00:07:40,950 you know, you actually have 170 00:07:40,950 --> 00:07:43,370 you know, those, I guess features 171 00:07:43,370 --> 00:07:45,560 you know, for basic authentication, 172 00:07:45,560 --> 00:07:47,210 or basic HTTP authentication, 173 00:07:47,210 --> 00:07:49,760 but it has several drawbacks, right. 174 00:07:49,760 --> 00:07:52,470 So there's no standard way to log out. 175 00:07:52,470 --> 00:07:55,610 There's no way to customize the login experience. 176 00:07:55,610 --> 00:07:58,800 The client needs to prompt users for credentials, 177 00:07:58,800 --> 00:08:02,390 collect and encode those into the header. 178 00:08:02,390 --> 00:08:04,970 And this is actually done by the browser by the way. 179 00:08:04,970 --> 00:08:07,780 And then the client needs to secure the cache 180 00:08:07,780 --> 00:08:11,350 credentials for a reasonable period of time. 181 00:08:11,350 --> 00:08:13,030 There's also fundamentally, insecurity 182 00:08:13,030 --> 00:08:14,190 as the full credentials actually, 183 00:08:14,190 --> 00:08:15,920 are passing over the wire. 184 00:08:15,920 --> 00:08:16,753 And that's the reason 185 00:08:16,753 --> 00:08:18,230 that you actually have to put TLS on it. 186 00:08:18,230 --> 00:08:20,080 But you know, again, hopefully, 187 00:08:20,080 --> 00:08:22,210 you know, you don't encounter some of these. 188 00:08:22,210 --> 00:08:24,157 There's many different problems, 189 00:08:24,157 --> 00:08:25,847 especially in the implementations 190 00:08:25,847 --> 00:08:27,910 and not not so much in, you know, 191 00:08:27,910 --> 00:08:31,060 yes, that the technology actually has a lot of drawback. 192 00:08:31,060 --> 00:08:33,060 But a lot of people actually have implemented very, 193 00:08:33,060 --> 00:08:35,150 very young security in the past. 194 00:08:35,150 --> 00:08:37,820 Now, there's also an HTTP form based authentication. 195 00:08:37,820 --> 00:08:39,080 So in other words, you know, 196 00:08:39,080 --> 00:08:42,820 an HTML form that is actually probably the most popular 197 00:08:42,820 --> 00:08:44,670 form of authentication, you know, 198 00:08:44,670 --> 00:08:46,980 because it's actually simple as well. 199 00:08:46,980 --> 00:08:48,440 And it allows the login experience 200 00:08:48,440 --> 00:08:50,330 to be completely customized 201 00:08:50,330 --> 00:08:52,780 unlike basic authentication, right. 202 00:08:52,780 --> 00:08:55,580 So this technique is actually simple, 203 00:08:55,580 --> 00:08:57,670 like as I mentioned before, 204 00:08:57,670 --> 00:09:01,510 basically just prompts the user for username and password 205 00:09:01,510 --> 00:09:04,390 using a custom HTML form, 206 00:09:04,390 --> 00:09:06,810 and then it sends those credentials to the server 207 00:09:06,810 --> 00:09:07,680 in the next request. 208 00:09:07,680 --> 00:09:09,970 So there's no standardization implementations, 209 00:09:09,970 --> 00:09:12,535 you know, all of them are actually done ad hoc. 210 00:09:12,535 --> 00:09:15,990 Now it requires, so these HTTP form based authentication 211 00:09:15,990 --> 00:09:19,740 requires the use of SSL and TLS connections, of course, 212 00:09:19,740 --> 00:09:22,960 definitely the credentials are gonna be sent 213 00:09:22,960 --> 00:09:24,560 over the clear text. 214 00:09:24,560 --> 00:09:26,650 So you don't want to do that. 215 00:09:26,650 --> 00:09:30,880 Now, there's another format or form 216 00:09:30,880 --> 00:09:34,690 called the Digest Access Authentication, or DAA. 217 00:09:34,690 --> 00:09:36,820 And that was created to, you know, 218 00:09:36,820 --> 00:09:39,420 to address the fact of basic authentication 219 00:09:39,420 --> 00:09:42,370 since the full credentials to the server. 220 00:09:42,370 --> 00:09:46,530 And in this case, DAA or Direct Access Authentication 221 00:09:46,530 --> 00:09:51,530 only sends an MD5 hash to the server. 222 00:09:51,930 --> 00:09:53,630 It actually includes some additional features 223 00:09:53,630 --> 00:09:57,080 like a nonce and protection against you know, 224 00:09:57,080 --> 00:09:58,490 anti replay attack. 225 00:09:58,490 --> 00:10:00,440 However, you know, you gotta know 226 00:10:00,440 --> 00:10:03,980 that MD5 is not secure, right? 227 00:10:03,980 --> 00:10:06,580 That just access authentication schemes 228 00:10:06,580 --> 00:10:11,290 within MD5 is considered insecure. 229 00:10:11,290 --> 00:10:12,300 And this is because 230 00:10:12,300 --> 00:10:15,530 it has a whole bunch of coalition attacks 231 00:10:15,530 --> 00:10:17,060 that can be possible. 232 00:10:17,060 --> 00:10:20,420 And of course, it's a weak hashing algorithm, right? 233 00:10:20,420 --> 00:10:21,870 Now there's another method 234 00:10:21,870 --> 00:10:25,410 called the Lightweight Third-party Authentication or LTPA. 235 00:10:25,410 --> 00:10:28,860 And LTPA is actually not an IBM proprietary method 236 00:10:28,860 --> 00:10:31,790 that was created to do single sign on, right? 237 00:10:31,790 --> 00:10:35,100 It actually is, has to be used in conjunction 238 00:10:35,100 --> 00:10:37,150 with another authentication technique 239 00:10:37,150 --> 00:10:38,610 to initially authenticate the user. 240 00:10:38,610 --> 00:10:40,960 And then once the user is actually logged in, 241 00:10:40,960 --> 00:10:43,880 then the LTP, a token or you know, 242 00:10:43,880 --> 00:10:46,550 the cookie is actually created. 243 00:10:46,550 --> 00:10:49,540 Now there's another method, which is very, 244 00:10:49,540 --> 00:10:52,390 very popular nowadays it's called OAuth2. 245 00:10:52,390 --> 00:10:55,000 So of course, there's a processor, just OAuth. 246 00:10:55,000 --> 00:10:57,510 But a strictly speaking, OAuth2 is actually 247 00:10:57,510 --> 00:10:59,920 an authorization scheme. 248 00:10:59,920 --> 00:11:00,950 In other words, you know, 249 00:11:00,950 --> 00:11:03,310 before beginning the actual OAuth process, 250 00:11:03,310 --> 00:11:06,760 the consumer application must first register 251 00:11:06,760 --> 00:11:08,590 with the provided application. 252 00:11:08,590 --> 00:11:11,180 And this is actually a manual one time process 253 00:11:11,180 --> 00:11:14,900 that typically involves providing some basic information 254 00:11:14,900 --> 00:11:15,780 about the application, 255 00:11:15,780 --> 00:11:18,675 like the name, the website, you know, some logo, 256 00:11:18,675 --> 00:11:20,210 you know, it all depends, right? 257 00:11:20,210 --> 00:11:23,960 So there's also a redirect URI that can actually be used 258 00:11:23,960 --> 00:11:25,790 for redirecting the user, 259 00:11:25,790 --> 00:11:28,393 from the provider back to the consumer web server, 260 00:11:29,300 --> 00:11:31,280 browser based or mobile app, right. 261 00:11:31,280 --> 00:11:32,500 So all of them, you know, 262 00:11:32,500 --> 00:11:35,023 actually use these type of technologies. 263 00:11:35,023 --> 00:11:38,210 And that redirect URI 264 00:11:38,210 --> 00:11:42,663 must be provided to prevent certain attack vectors. 265 00:11:43,540 --> 00:11:44,790 Now the sequence starts 266 00:11:44,790 --> 00:11:47,950 with a consumer making the OAuth2 267 00:11:47,950 --> 00:11:50,220 resource request to the provider. 268 00:11:50,220 --> 00:11:52,500 The provider application actually informs the user 269 00:11:52,500 --> 00:11:54,130 of the requests and prompt them 270 00:11:54,130 --> 00:11:57,760 to authenticate if they actually have not done so. 271 00:11:57,760 --> 00:12:01,280 Now, the way that the provider authenticates the user 272 00:12:01,280 --> 00:12:03,610 has nothing to do with OAuth2. 273 00:12:03,610 --> 00:12:06,240 Any authentication schemes actually can be used 274 00:12:06,240 --> 00:12:08,420 once the user is authenticated, 275 00:12:08,420 --> 00:12:11,170 and has a granted permission permission 276 00:12:11,170 --> 00:12:13,930 to the provider application, 277 00:12:13,930 --> 00:12:16,380 the control reverse back to the consumer. 278 00:12:16,380 --> 00:12:17,430 And that's actually done, 279 00:12:17,430 --> 00:12:19,750 the other register redirect URI. 280 00:12:19,750 --> 00:12:24,330 Now, you have actually accessed in an access token 281 00:12:24,330 --> 00:12:25,980 that allows, you know, 282 00:12:25,980 --> 00:12:30,230 the application to access the resources in the provider. 283 00:12:30,230 --> 00:12:31,410 Now, this access token 284 00:12:31,410 --> 00:12:34,230 is actually provided in the HTTP header 285 00:12:34,230 --> 00:12:36,350 for subsequent request. 286 00:12:36,350 --> 00:12:38,440 And the specifics of these interaction 287 00:12:38,440 --> 00:12:40,610 between the consumer and the provider 288 00:12:40,610 --> 00:12:43,830 depends on the, whether they're several, 289 00:12:43,830 --> 00:12:47,630 the server hosted web sites, you know, 290 00:12:47,630 --> 00:12:49,350 where browser based applications 291 00:12:49,350 --> 00:12:50,610 or mobile applications, right. 292 00:12:50,610 --> 00:12:53,920 So the each of them have their own implementation. 293 00:12:53,920 --> 00:12:56,410 Now, what makes OAuth notable 294 00:12:56,410 --> 00:12:58,002 is the fact that their users 295 00:12:58,002 --> 00:13:01,480 credentials are never exposed to the consumer application. 296 00:13:01,480 --> 00:13:04,580 The consumer is actually going to give in a temporary token, 297 00:13:04,580 --> 00:13:05,710 that actually expires, 298 00:13:05,710 --> 00:13:07,710 that's the reason that is temporary, 299 00:13:07,710 --> 00:13:10,120 which can also be revoked by the user 300 00:13:10,120 --> 00:13:12,560 or the provider application at a time 301 00:13:12,560 --> 00:13:14,210 that you don't need those anymore, right. 302 00:13:14,210 --> 00:13:16,930 So, and of course, that's what you actually see a lot 303 00:13:16,930 --> 00:13:20,113 in the APIs nowadays, using OAuth2, 304 00:13:21,050 --> 00:13:23,250 and if those tokens actually don't expire, 305 00:13:23,250 --> 00:13:25,930 or for some reason the implementer or the developer, 306 00:13:25,930 --> 00:13:28,610 you know, they put, you know, they expire it, 307 00:13:28,610 --> 00:13:30,000 let's say for a year, 308 00:13:30,000 --> 00:13:31,650 that is actually a very unsecure method. 309 00:13:31,650 --> 00:13:35,100 So whenever you actually doing the pentesting engagement 310 00:13:35,100 --> 00:13:38,616 and look at that, look at how the application is, 311 00:13:38,616 --> 00:13:41,890 is whether expiring or not expiring, or you know, 312 00:13:41,890 --> 00:13:44,920 how the actual, you know, credentials 313 00:13:44,920 --> 00:13:47,630 are being exchanged or not exchanged 314 00:13:47,630 --> 00:13:50,090 using these methods, right. 315 00:13:50,090 --> 00:13:52,050 So not only OAuth2. 316 00:13:52,050 --> 00:13:54,090 Now going back to OAuth2, 317 00:13:54,090 --> 00:13:57,180 it actually mandates that you have to use dealers. 318 00:13:57,180 --> 00:13:58,820 Now there's another method 319 00:13:58,820 --> 00:14:01,680 that is also used at nowadays called OpenID. 320 00:14:01,680 --> 00:14:03,650 And it's basically an open standard 321 00:14:03,650 --> 00:14:07,060 for providing authentication of an identity. 322 00:14:07,060 --> 00:14:11,810 There are many OIDs, identity providers out there. 323 00:14:11,810 --> 00:14:15,650 Things like Yahoo, Flicker, Google, WordPress 324 00:14:15,650 --> 00:14:17,200 and many others, right? 325 00:14:17,200 --> 00:14:19,200 That they actually use OpenID. 326 00:14:19,200 --> 00:14:21,820 Now, any client that outsources authentication 327 00:14:21,820 --> 00:14:24,070 to one of these identity providers 328 00:14:24,070 --> 00:14:29,070 are actually known to be the Relaying Party or the RP. 329 00:14:29,410 --> 00:14:32,590 Now, the OpenID, the specification actually has 330 00:14:32,590 --> 00:14:34,300 a set of extensions. 331 00:14:34,300 --> 00:14:38,010 One of them is called the Attribute Exchange Extension 332 00:14:38,010 --> 00:14:42,930 and it was actually done to profile attributes. 333 00:14:42,930 --> 00:14:45,390 Like the name and the gender and you know, 334 00:14:45,390 --> 00:14:49,360 some other identity elements 335 00:14:49,360 --> 00:14:52,700 to be provided from the OpenID identity provider 336 00:14:52,700 --> 00:14:56,810 to the Relaying Party, to the RP. 337 00:14:56,810 --> 00:14:59,760 Now, essentially OID allows, 338 00:14:59,760 --> 00:15:04,760 or OpenID allows a user to maintain a single profile 339 00:15:06,100 --> 00:15:10,200 with an openID identity provider of their choice. 340 00:15:10,200 --> 00:15:13,300 And also to authenticate with a third 341 00:15:13,300 --> 00:15:15,940 any third party website, or where mobile application 342 00:15:15,940 --> 00:15:19,630 that actually participates as a Relaying Party. 343 00:15:19,630 --> 00:15:22,240 Now the last method that I'm gonna be covering 344 00:15:22,240 --> 00:15:27,240 is called the Security Assertion Markup Language or SAML. 345 00:15:27,790 --> 00:15:30,430 A lot of people actually referred to it as SAML. 346 00:15:30,430 --> 00:15:33,620 It is an XML based open standard 347 00:15:33,620 --> 00:15:35,760 that is maintained by OASIS. 348 00:15:35,760 --> 00:15:36,950 It's actually used for 349 00:15:36,950 --> 00:15:39,000 both authentication and authorization. 350 00:15:39,000 --> 00:15:41,110 And it's also capable of exchanging 351 00:15:41,110 --> 00:15:43,320 user profile attributes as well. 352 00:15:43,320 --> 00:15:48,320 Now previous versions of SAML relied on SOAP over HTTP, 353 00:15:48,530 --> 00:15:50,370 but newer versions you know, 354 00:15:50,370 --> 00:15:53,533 so from version V2.0 and onwards, 355 00:15:53,533 --> 00:15:56,030 it has a little bit more flexibility 356 00:15:56,030 --> 00:15:58,020 because supports flexible bindings 357 00:15:58,020 --> 00:16:02,330 and if exchanges are between the user an identity provider, 358 00:16:02,330 --> 00:16:04,710 and the user and the service provider, 359 00:16:04,710 --> 00:16:07,640 then SOAP is actually not necessary, right? 360 00:16:07,640 --> 00:16:12,379 So SAML2 directs later, and the OpenID, 361 00:16:12,379 --> 00:16:15,771 are actually different solutions to the same authentication 362 00:16:15,771 --> 00:16:17,640 and authorization challenge, right? 363 00:16:17,640 --> 00:16:22,640 So, now, SAML and OAuth2 can actually coexist. 364 00:16:23,142 --> 00:16:27,680 Now nowadays, a lot of API is actually standardized in, 365 00:16:27,680 --> 00:16:29,580 in using OAuth2, right? 366 00:16:29,580 --> 00:16:31,600 So a lot of people actually use that. 367 00:16:31,600 --> 00:16:34,150 And SAML is actually the current leading standard 368 00:16:34,150 --> 00:16:38,820 for inter-domain web Single Sign-on or web SSO. 369 00:16:38,820 --> 00:16:42,810 If you look at it, SSO, whether it's OpenID, 370 00:16:42,810 --> 00:16:46,420 or a SAML for sure, those are the most prevalent ones. 371 00:16:46,420 --> 00:16:51,420 In the case of modern API's, you see a lot of OAth2. 372 00:16:51,580 --> 00:16:54,061 So whenever you're actually doing penetration testing, 373 00:16:54,061 --> 00:16:57,079 one, become familiar with, you know, with those standards, 374 00:16:57,079 --> 00:16:59,270 become familiar of how applications 375 00:16:59,270 --> 00:17:02,470 actually may use them, may not use them, and so on. 376 00:17:02,470 --> 00:17:03,890 And then later in the course, 377 00:17:03,890 --> 00:17:06,240 actually we're gonna be covering several, 378 00:17:06,240 --> 00:17:08,870 you know, techniques on how to 379 00:17:08,870 --> 00:17:11,450 even test, you know, some of these modern applications 380 00:17:11,450 --> 00:17:13,060 and what tools to use 381 00:17:13,060 --> 00:17:16,220 and what flaws you can take advantage of 382 00:17:16,220 --> 00:17:18,170 in your penetration testing engagement.