WEBVTT 00:00.000 --> 00:16.000 Hello everybody, we are very happy to talk today about how to set your SPA in our studio. 00:16.000 --> 00:22.000 We hope to have sure our talk, let me introduce ourselves briefly. 00:22.000 --> 00:26.000 My name is Takashi Nounimatsu from Japan. 00:26.000 --> 00:32.000 The key work maintainer and also working at Hitachi Limited to Japan. 00:32.000 --> 00:40.000 My name is Alexander Schwarz and I am also a key clerk maintainer working for Red Hat. 00:40.000 --> 00:52.000 So today's main topic is about how to set your single page application in our studio. 00:52.000 --> 01:00.000 So in the beginning of this talk, I would like to describe what SPA in our studio is. 01:00.000 --> 01:14.000 So in the youths, like you, this is not the basis and it runs the SPA as all students cry and own browser. 01:14.000 --> 01:19.000 So the first we need to use the existing browser to receive some services. 01:19.000 --> 01:33.000 After that, SPA sends authorization request to authorize and show us by following us to a protocol in the receives authorization code. 01:33.000 --> 01:43.000 After that, SPA sends the token request to authorize your subbar with this authorization code. 01:43.000 --> 01:55.000 And finally, this SPA sends API access request to the SPA and receive its response. 01:55.000 --> 02:05.000 The actual example of SPA in our studio is key crooks account console or unadmin console. 02:05.000 --> 02:15.000 The both uses the key crooks.js. It works as fast party or security and application. 02:15.000 --> 02:29.000 Next, I'd like to introduce two measures that we can list where we encounter if we use SPA in our studio. 02:29.000 --> 02:37.000 The first set we do is misuse over storing authorization code. 02:37.000 --> 02:45.000 So the SPA after SPA receive the authorization code from the authorization server. 02:45.000 --> 02:58.000 If an attacker steal this authorization code, then this attacker can get a valid access token from this authorization server. 02:58.000 --> 03:06.000 However, in return for this stolen authorization code. 03:06.000 --> 03:14.000 So one counter measure to mitigate this risk is client authentication. 03:14.000 --> 03:22.000 When authorizes a subbar receive token request from the SPA from the client application, 03:22.000 --> 03:30.000 then authorizes a subbar to do client authentication against the author's client. 03:30.000 --> 03:40.000 However, the SPA is usually treated as a public client. 03:40.000 --> 03:54.000 In return it means that it's not able to do client authentication because it's not able to, it's not capable of making the confidentiality of credentials. 03:54.000 --> 04:00.000 For example, use for client authentication access authorization server. 04:00.000 --> 04:14.000 So therefore, considering that point, the client authentication as a counter measure agency is not to be effective. 04:14.000 --> 04:20.000 The second security list is misuse of storing access token. 04:20.000 --> 04:27.000 Then after SPA receives an access token from authorizes a subbar. 04:27.000 --> 04:40.000 If the attacker can steal this access token, then this attacker can access the API subbar by using this stolen access token. 04:40.000 --> 04:59.000 Because according to the SPA's application defined by RFC6750, it states that access token is treated as Bella token, 04:59.000 --> 05:07.000 which means that every client who holds this client can use this token. 05:07.000 --> 05:11.000 So, actual example in a real world is train ticket. 05:11.000 --> 05:19.000 Why? There is another type of token called senda consturaning token. 05:19.000 --> 05:27.000 In this case, only specific client application can use this type of desktop token. 05:27.000 --> 05:32.000 So, actual example in a real world is passport. 05:32.000 --> 05:37.000 But there are several ways to realize this senda consturaning token. 05:37.000 --> 05:47.000 There, one of those such ways is to ausmTLS defined by RFC8705. 05:48.000 --> 06:03.000 However, it requires client application to manage seturary x5.9 certificate and its corresponding private key seturary. 06:03.000 --> 06:12.000 But, however, we consider in the point that SPA is treated as public client. 06:12.000 --> 06:22.000 Similarly, the SPA is difficult to seturary for its difficult for SPA to manage seturary. 06:22.000 --> 06:27.000 The x5.9 certificate and its corresponding private key. 06:27.000 --> 06:37.000 So, therefore, the countermeasure therefore, this certificate is as senda consturant token. 06:37.000 --> 06:43.000 It seems not to be effective for SPA in those two. 06:43.000 --> 06:55.000 Then, so next, I would like to introduce the countermeasure for both two major seturaries that may arise in SPA in those two. 06:55.000 --> 06:58.000 It is called DeepOp. 06:58.000 --> 07:06.000 Demonsturating also demonstrate thing proof of possession called DeepOp. 07:06.000 --> 07:23.000 It defined by RFC9449 and it allows us to demonstrate and verify a senda of the message on HTTP is a holder of an asymmetric cryptographic key. 07:23.000 --> 07:38.000 So, therefore, by using this SPA application, we can rewrite the senda consturant token by binding this key with a token in a cryptographic way. 07:38.000 --> 07:52.000 Next, so I would like to describe how to mitigate the risk of misuse of stolen authorization code by applying the DeepOp's optional future DeepOp. 07:53.000 --> 08:07.000 In this case, before SPA sent authorization request to also as a subscriber, SPA need to generate the temporal DeepOp key pair, public key and private key. 08:07.000 --> 08:13.480 And then, SPA needed to calculate hash value of this public key. 08:13.480 --> 08:16.440 It is called the Pope JKT. 08:16.440 --> 08:21.080 And after that, SPA sent authorization request 08:21.080 --> 08:24.800 to the author's server with this deep object key. 08:24.800 --> 08:29.800 Then, where, author's server received this request, 08:29.800 --> 08:34.720 author's server generated an authorization code 08:34.720 --> 08:41.120 and bind this authorization code with the Pope JKT. 08:41.120 --> 08:49.600 So, after that, the SPA, after SPA received this authorization code, 08:49.600 --> 08:55.360 then, before the SPA sent token request to author's server, 08:55.360 --> 09:01.400 the SPA needed to generate the data code deep of proof. 09:01.400 --> 09:05.080 It includes the public key itself. 09:05.080 --> 09:10.680 And SPA needed to generate a signature against this deep of proof 09:10.680 --> 09:17.240 by using this private key and attach this signature to this pop proof. 09:17.240 --> 09:24.680 And finally, this SPA sent token request with authorization code and this deep of proof. 09:24.760 --> 09:31.480 So, therefore, if attacker can steal this authorization code, 09:31.480 --> 09:35.880 this attacker cannot create valid deep of proof, 09:35.880 --> 09:44.120 because it does not hold the SPA's temporal private key. 09:44.120 --> 09:51.960 The next, I would like to describe how to mitigate the risk of misuse 09:51.960 --> 09:57.400 of storing access token by applying the deep of future. 09:57.400 --> 10:01.160 When author's authorization server received token request, 10:01.160 --> 10:05.880 we also associated your code and deep of proof from SPA, 10:05.880 --> 10:13.320 then, the author's server create an authorization access token, 10:13.320 --> 10:20.760 and bind the public key included in to this deep of proof, 10:20.840 --> 10:23.880 with this access token. 10:23.880 --> 10:30.520 Then, after that, SPA after SPA received this access token, 10:30.520 --> 10:35.640 the SPA 22 sent API access request to API server, 10:35.640 --> 10:42.600 but in this case, SPA need to create deep of proof again. 10:42.600 --> 10:46.360 And it also includes the same public key itself, 10:46.360 --> 10:52.280 and SPA need to regenerate the signature against this deep of proof, 10:52.280 --> 10:55.880 and put this signature onto this pop proof. 10:55.880 --> 11:04.120 And SPA finally sent this API access request with access token and deep of proof. 11:04.120 --> 11:09.800 So, when API server received this API access request, 11:10.600 --> 11:16.280 API server can verify the weather a holder of public key 11:16.280 --> 11:22.120 included in this deep of proof is equal to the sender of the API access 11:22.120 --> 11:25.320 request number six, namely the SPA. 11:26.520 --> 11:35.400 Then, after that, the API server can also verify whether the sender of the API request number six 11:35.480 --> 11:39.800 is equal to sender of the token request number four. 11:41.160 --> 11:46.120 Therefore, if an attacker can steal this access token, 11:46.120 --> 11:51.560 then, this attacker cannot create a valid deep of proof. 11:51.560 --> 11:56.920 Then, because the attacker does not hold the private key of the SPA 11:56.920 --> 11:58.280 simpler deep of key pair. 12:00.120 --> 12:05.240 So, next, we would like to do some demonstration to show how it works. 12:05.240 --> 12:12.760 I broke it. 12:15.800 --> 12:20.680 Almost, that's not pointing upwards, but maybe you're used to looking. 12:23.000 --> 12:26.120 So, I want to show you what we've shown on this slide, 12:26.120 --> 12:29.480 all that it works in practice, with already available tools. 12:30.200 --> 12:32.680 So, what I'm bringing here today is JavaScript. 12:33.240 --> 12:37.480 A single page application with view and upon by open my decline, 12:37.480 --> 12:42.760 that's a positive pop. Then, I bring you to a key cloak, which is also a positive pop, 12:42.760 --> 12:46.040 and I bring you to a quarters application with the nimbos, 12:46.040 --> 12:49.720 allows to SDK, which is also a positive pop, and they all talk together, 12:49.720 --> 12:50.920 and I will show that in a demo. 12:52.920 --> 12:55.800 So, let's start with key cloak. I have key cloak here, 12:55.800 --> 12:59.720 I'm planning to refresh the page to make sure that I can really log in. 12:59.720 --> 13:03.560 So, I have a test realm here, I'm not supposed to secure a password anyway, 13:03.560 --> 13:08.680 but then, anyway, I have a client here for the OpenModConnect view, 13:08.680 --> 13:11.400 and I have an advanced tab, and somehow in the advanced tab, 13:12.520 --> 13:14.440 I can search for D-pop and D-pop is enabled. 13:15.320 --> 13:18.440 So, this is something you need to do. You need to set up a client with D-pop enabled. 13:18.440 --> 13:22.040 You also need to start key cloak with the feature preview feature D-pop enabled, 13:22.040 --> 13:26.280 and then you have a working key cloak server that can do P-pop. 13:26.760 --> 13:31.400 I also have the view application that I opened up here, 13:32.600 --> 13:37.240 so it now asks me to log in, I log in with test, 13:38.040 --> 13:39.800 and the very secret password. 13:41.160 --> 13:46.360 And I log in here, and what it does, it's this PANBA OpenModD clients, 13:46.360 --> 13:49.000 talking to the key cloak server, I'm logging in, 13:50.120 --> 13:52.920 setting in an authentication request, I authenticate here, 13:53.880 --> 14:00.200 and you will then see that, okay, so you're probably wanted to, 14:00.200 --> 14:07.720 yeah, I get something back here, so I redirect to key cloak, 14:08.520 --> 14:14.840 come back from key cloak, I get here all the different headers with OpenModD Connect, 14:14.840 --> 14:20.280 and I was with D-pop, I changed the token here, 14:21.240 --> 14:24.200 I send all these D-pop headers that you will see here, for example, 14:24.200 --> 14:26.760 the D-pop header that Takaashi talked about earlier, 14:26.760 --> 14:29.320 it's all sent to key to exchange the token, 14:29.320 --> 14:33.320 I get all the information here set up, 14:33.640 --> 14:36.920 and I'm also already talking to Quarkus here, 14:36.920 --> 14:40.520 so the first request fails, because I'm doing something else here, 14:40.520 --> 14:43.720 that's also doing a non-s, so can make sure that any request 14:43.720 --> 14:47.080 at the single page app sends is executed only once, 14:47.240 --> 14:49.880 it then the first request fails, it sends the server sends back 14:49.880 --> 14:53.080 a non-s to the client, the client resens the request automatically, 14:53.080 --> 14:56.680 that's all part of the Takaashi Quick Library, which is nice, so, 14:59.160 --> 15:04.760 yes, with that all set up, I'm shown that it works, 15:05.320 --> 15:08.680 I have a second demo that also shows that this works with, 15:09.560 --> 15:16.920 with Apache 2, with most outs of my D-Connect, 15:16.920 --> 15:18.760 I'm seeing I'm running a bit out of time here, 15:19.400 --> 15:22.440 thing is, when you do something like this, you can have a browser, 15:22.440 --> 15:26.520 redirecting to Apache 2, and Apache 2 will redirect to KeyCloud, 15:26.520 --> 15:30.920 does all the D-pop magic, and eventually sends the request 15:30.920 --> 15:33.640 after it's been authenticated to the original application, 15:33.640 --> 15:37.560 and in my demo, there's a stand, a PHP application, 15:37.560 --> 15:41.000 so when I log in here, I'm already logged in because it's single-son on it, 15:41.000 --> 15:43.720 will not show me the login page again, but you then see here, 15:43.720 --> 15:49.000 all the open-mighty connect stuff sent back from Apache, as HPP had 15:49.000 --> 15:52.840 to my application running as PHP inside of Apache. 15:53.720 --> 15:58.440 So, you see there already a lot of tools out there that work well together with D-pop, 15:59.640 --> 16:04.280 so that was KeyCloud, that was the numerous SDK, that was the Pandra client, 16:05.080 --> 16:10.600 that was the Apache module there, and it's great that we can finally bind the payload, 16:10.600 --> 16:15.480 and we're sending two to the actual headers and authentication that we're doing there. 16:17.080 --> 16:22.920 Right, when you do an application like this, you will see that more headers are sent back 16:22.920 --> 16:27.880 and files, and you might want to configure your cores in the way that it works, 16:27.880 --> 16:31.240 so that it really does all the additional headers, for example, 16:31.240 --> 16:35.240 something, some pitfall nights here that you really need to make sure that this new header 16:35.240 --> 16:41.080 D-pop and D-pop non-s are really exposed in a right way to make this course work properly. 16:42.280 --> 16:49.400 All right, so yeah, handing them over back to security configurations, 16:49.720 --> 16:53.240 if you're too careful, and we might have soon take the questions. 17:02.920 --> 17:04.200 Yeah, no, okay, minutes or so. 17:04.200 --> 17:11.400 Okay, I see. So, finally, I would like to briefly describe the CTT conservation. 17:11.400 --> 17:18.440 We use the SPNNS2, and we need to apply both counter-measure for the CTT 17:18.440 --> 17:23.160 squandering to misuse of slow-ontortization code and the misuse store-down system. 17:23.880 --> 17:30.600 The E, the counter-measure for risk-one locks, and attacker can receive the 17:30.600 --> 17:38.040 access token by using attacker's own D-pop key pairs. So, therefore, both counter-measure needs it. 17:38.600 --> 17:47.880 And also, we recommend that you apply several counter-measure for the misuse of a slow-ontortization code. 17:48.120 --> 17:56.120 As you may know, the proof T4 code exchange code PICC defined by ROC 7636. 17:56.120 --> 18:00.680 That also can prevent this type, can't mitigate this type of risk. 18:01.400 --> 18:08.440 So, therefore, considering this point, we recommend the following options for counter-measure combination, 18:08.440 --> 18:16.120 upper-end D-pop, JKT, D-pop, or PICC, D-pop, or PICC, D-pop, or PICC, D-pop, JKT, D-pop, 18:16.360 --> 18:25.000 or applied. Then, today's, in our talk, we introduced the briefly SPN announced to 18:25.000 --> 18:32.680 and describe the two major CTT risks, and introduced the counter-measure for such a CTT risk in SPN 18:32.680 --> 18:39.480 announced to call the D-pop. And so, the finally, we described briefly the 18:39.480 --> 18:50.200 CTT concentration, where we used this D-pop in SPN in O2. So, this topic is a little bit complicated. 18:50.200 --> 18:56.520 So, therefore, it took a lot of time to describe here. So, to say what precisely, this slide 18:56.520 --> 19:01.880 will include a lot of information. So, therefore, if you are interested in this topic, please 19:02.680 --> 19:07.880 download this slide and look at this slide afterwards. Okay, thank you very much. 19:10.040 --> 19:12.520 Thank you. 19:14.920 --> 19:24.840 There is time for some brushstrokes. Yes, so, part of the D-pop you do is store the D-pop in Stolen. 19:24.840 --> 19:27.560 Stolen authorizes a store in access to the D-pop. 19:27.560 --> 19:32.520 Why did you translate that in my guess is that the most common way that the D-pop 19:32.600 --> 19:38.760 gets stolen from a broken SPN application is through OSI-15 attacks. And when you have 19:38.760 --> 19:45.080 the OSI-15 attack, the attack is still the priority without any problem. So, is it even possible 19:45.080 --> 19:54.440 to secure SPN's using the world? Okay, so, can you please, the D-PT risk question? 19:54.440 --> 20:01.400 Okay, we should repeat it for the microphone, okay. So, the question is, if the 20:01.400 --> 20:06.680 attacker steals the key material out of the browser, it can do everything and it's not about 20:08.520 --> 20:12.520 stealing it only in transit. Well, stealing in transit, there are sometimes proxies that do 20:13.080 --> 20:17.000 decryption encryption. Yeah, but then stealing in a browser. The examples are shown today, 20:17.000 --> 20:22.840 they use the extensions web crypto. So, this D-pop key pair is generated in the browser 20:24.520 --> 20:30.040 inside the browser, but JavaScript can never extract it. So, we can do the JavaScript application 20:30.040 --> 20:34.920 can do cryptographic operations with the key in the browser, but never catching the key. So, that's 20:36.200 --> 20:43.400 web crypto API. If you find it in access, explore the SPN application, you will not be able to 20:43.400 --> 20:47.480 extract the pen. Yes, that's right. Yeah, I can't extract the key material. 20:49.880 --> 20:58.600 I can, I can maybe, like, I could create tokens, but they would be only valid for that time. I 20:58.600 --> 21:02.680 could, I can't generate them in the future, but only at that very moment. So, that's possible, 21:02.680 --> 21:08.280 but I can't extract the key material and all the data technique to happen in that one browser. 21:08.280 --> 21:13.000 I can't extract the material and do it in another browser or later, or after the user looked out. 21:13.000 --> 21:15.480 So, that's it. That's the advantage that we can do here. 21:19.480 --> 21:20.680 There's a question back there. 21:21.480 --> 21:31.320 Also, one point I would like to mention, this type of keypills, this type of keypills lifetime, 21:31.320 --> 21:39.800 is very short. So, therefore, the attack cards, the time window is very narrow. So, therefore, 21:40.040 --> 21:44.760 it can immediately, this type of risk, I think so. 21:54.760 --> 21:58.440 So, the question was, do we need to state on the authorization server? 22:00.520 --> 22:08.280 Yes. So, yes, in the way, if you're using launches, your resource provider needs to know that 22:08.280 --> 22:12.680 this launch has not yet been sent or generated maybe with a time term in what not. 22:13.720 --> 22:17.800 You will always, as a user, have a session with the authorization server with keyclock into 22:17.800 --> 22:22.760 this example. So, yes, there are sessions involved and state to be held on each of the 22:22.760 --> 22:50.600 parties involved here. So, if the application is renewing that tokens with keyclock, 22:50.680 --> 22:55.400 keyclock will need to check the signatures on the token on the refresh token, it's sending and 22:55.400 --> 23:03.160 the cryptographic things that it's done stuff on. If you receive a token from, if you're the 23:03.160 --> 23:07.880 authorization resource server and receive something from the application, it depends, 23:07.880 --> 23:16.120 maybe the token is just a drop token. So, you can do a cryptographic operations on the access token 23:16.200 --> 23:21.080 or you receive on the D-pop key material or you receive and you can do it 100% locally, 23:21.080 --> 23:29.240 if it's all JSON web token based. If it's opaque token that you can't verify yourself, 23:29.240 --> 23:35.400 you will send your access token to the authorization server for token into spectrum and you will get back 23:37.000 --> 23:42.280 the identity of the D-pop key it has been generated for and then you can use that identity, 23:42.280 --> 23:47.640 this ID of the key that has also been sent by the user to figure out okay, this access token was 23:47.640 --> 23:56.200 valid as such and is it still, is it connected to the proof that this single-paid application 23:56.200 --> 24:04.200 has sent to me and then I'm sure okay, this is fine. But okay, we out of time, so I'm happy to continue 24:04.200 --> 24:08.440 the discussion outside. We are also having some more talks tomorrow about keyclock and the identity 24:08.440 --> 24:14.520 key in access management bedroom and we also be at the CNCF stand here at Boston. See you there.