WEBVTT 1 00:00:00.620 --> 00:00:03.970 CHRIS WEBBER: ♬ It's time to return to your screens ♬ 2 00:00:03.970 --> 00:00:09.410 All right, here we have Aaron Parecki, who actually was one of the people in the social 3 00:00:09.410 --> 00:00:13.430 web working group as well, and wrote quite a few standards in the social web working 4 00:00:13.430 --> 00:00:15.990 group, which is also where ActivityPub standardized. 5 00:00:16.010 --> 00:00:18.090 So welcome, Aaron. 6 00:00:18.110 --> 00:00:19.120 It's nice to see you again. 7 00:00:19.130 --> 00:00:24.620 And Aaron's been very involved in the OAuth standardization process. 8 00:00:24.620 --> 00:00:29.940 And is here to talk about how to fill one of the left open in the ActivityPub specs 9 00:00:31.790 --> 00:00:35.830 sections, which is the how to handle authorization. 10 00:00:36.140 --> 00:00:40.010 So why don't you why don't you -- why don't we open it up. 11 00:00:41.300 --> 00:00:46.310 AARON PARECKI: Yeah. Thanks. So I guess I can assume that hopefully at least most people have seen the 12 00:00:46.310 --> 00:00:51.950 talks. I'm not going to necessarily recap the contents of the talks, but happy to answer 13 00:00:51.950 --> 00:00:57.410 questions about that. I can also sort of give a quick, quick recap in case people are 14 00:00:57.410 --> 00:01:01.760 here who did not watch it yet, but fair warning. 15 00:01:02.030 --> 00:01:06.600 It is explained to better in the video than I would be able to recap here. 16 00:01:07.190 --> 00:01:10.850 So. Quick recaps are helpful, cool. 17 00:01:12.230 --> 00:01:20.510 So the general idea is ActivityPub left out a lot of pieces that need to get filled in 18 00:01:20.510 --> 00:01:23.530 later, that authorization being one of them. 19 00:01:23.900 --> 00:01:28.820 And I really think that OAuth is a perfect fit for the ActivityPub world for the 20 00:01:28.880 --> 00:01:30.830 client-to-server authentication and authorization piece. 21 00:01:31.220 --> 00:01:37.850 So the overall goal of OAuth is to -- well the original goal of OAuth was to let third 22 00:01:37.850 --> 00:01:43.610 party apps get access to data or let people use third party apps to create data. 23 00:01:43.620 --> 00:01:48.410 So I'm sure we're all familiar with the idea of third party Twitter apps back when that 24 00:01:48.410 --> 00:01:54.920 was like a thing that was popular before Twitter started shooting everything down and, 25 00:01:55.860 --> 00:02:00.270 what's been happening in the OAuth world is over the years, there's been a lot of work 26 00:02:00.270 --> 00:02:05.640 being done by a lot of different people to improve the security of it and make it useful 27 00:02:05.640 --> 00:02:09.480 in more different kinds of situations. 28 00:02:10.370 --> 00:02:14.750 And there is a -- definitely an 29 00:02:15.950 --> 00:02:22.100 opportunity to sort of pick up that work and then apply it to the ActivityPub space, and I 30 00:02:22.100 --> 00:02:27.590 have a feeling that some people here who are have written applications in the past with 31 00:02:27.590 --> 00:02:33.170 either against Twitter API itself or other applications in that generation, may be 32 00:02:33.170 --> 00:02:34.460 familiar with OAuth 1. 33 00:02:34.760 --> 00:02:37.700 And it turns out OAuth 2 is a completely different way of doing it. 34 00:02:37.700 --> 00:02:39.010 And it's actually a lot easier. 35 00:02:39.050 --> 00:02:43.550 So if you have used OAuth 1 in the past, the good news is it's not that complicated. 36 00:02:44.740 --> 00:02:47.830 It's not nearly as bad as that was, so the 37 00:02:49.040 --> 00:02:56.600 general, sort of, -- I didn't have slides for the talk, I was just doing a talk. 38 00:02:56.900 --> 00:02:58.580 So I don't even have slides to review right now. 39 00:02:58.580 --> 00:03:06.080 But the general idea with with OAuth is a user, we don't want to make users type 40 00:03:06.080 --> 00:03:11.480 passwords into applications because if you download someone's open source app or from an 41 00:03:11.480 --> 00:03:15.620 app store or whatever, that's like a third party app and you're trying to connect your 42 00:03:15.620 --> 00:03:21.770 own activitypub server to it, you don't necessarily trust that application to handle your 43 00:03:21.770 --> 00:03:26.660 password properly, even if you believe the developer is working and has everybody's best 44 00:03:26.660 --> 00:03:29.840 interests at heart. You can't even guarantee that the app isn't accidentally logging it 45 00:03:30.410 --> 00:03:34.790 or isn't accidentally using some other library that might be doing something sneaky. 46 00:03:34.880 --> 00:03:44.590 So the idea is to avoid passwords in applications by using an OAuth flow to 47 00:03:44.740 --> 00:03:49.930 grant tokens to apps that can then use the API so. 48 00:03:54.690 --> 00:03:59.160 With yeah, so I guess all of these questions coming up in the chat, so let me talk about 49 00:03:59.160 --> 00:04:03.300 some of these, because these these get into the content of the talk. 50 00:04:06.270 --> 00:04:10.530 So Michael from Friendica says, When I created the pump.io Connector for Friendica many 51 00:04:10.590 --> 00:04:13.250 years ago, they already had some OAuth that didn't need registering. 52 00:04:13.320 --> 00:04:15.330 And how does this compare with the new OAuth? 53 00:04:16.490 --> 00:04:18.530 I don't actually remember what. 54 00:04:19.680 --> 00:04:23.700 Pump.io did with OAuth, so I'm not sure how it compares, but. 55 00:04:24.770 --> 00:04:28.430 CHRIS WEBBER: It was OAuth 1 by the way, 56 00:04:28.850 --> 00:04:33.770 AARON PARECKI: That was -- that was what I was thinking, because that's then I have zero idea how they 57 00:04:33.770 --> 00:04:39.620 did it without registering, because OAuth 1 requires signing stuff with secrets that are 58 00:04:39.740 --> 00:04:40.870 set up in registration. 59 00:04:40.880 --> 00:04:42.980 It must have been some sort of dynamic registration at that point. 60 00:04:45.630 --> 00:04:54.170 So. This is something that is also left out of OAuth, which is the step of actually 61 00:04:54.170 --> 00:04:57.320 registering apps and establishing that relationship, so. 62 00:04:58.340 --> 00:05:06.610 Despite the idea of registering an app, is something that most, 63 00:05:07.660 --> 00:05:13.420 like, company or corporate services will want you to have to do because they want to make 64 00:05:13.420 --> 00:05:17.740 sure the developer agrees to the terms of service, they want to have that audit trail of 65 00:05:17.740 --> 00:05:20.800 knowing which API keys are given out to which 66 00:05:23.420 --> 00:05:24.870 developers and things like that, right? 67 00:05:24.890 --> 00:05:32.720 So that's the reason that you see in practice almost every OAuth system requiring some 68 00:05:32.720 --> 00:05:34.130 form of client registration. 69 00:05:34.400 --> 00:05:40.550 Usually in the form of -- you make an account at that API as a developer and you get API 70 00:05:40.550 --> 00:05:46.820 keys. Now, that obviously does not work in this world because everybody is bringing their 71 00:05:46.850 --> 00:05:48.730 own APIs into this ecosystem. 72 00:05:48.740 --> 00:05:57.080 Right. So I can spin up an activitypub server and the developer has zero relationship 73 00:05:57.080 --> 00:06:00.980 with my personal server and they can't go register for API. 74 00:06:01.160 --> 00:06:04.850 So we basically have to work around the need for client registration. 75 00:06:06.220 --> 00:06:13.750 So there are two options that are available, so OAuth has this concept of, it's an 76 00:06:13.750 --> 00:06:18.620 extension, it's not part of the core, and it's just an extension that some people have 77 00:06:18.660 --> 00:06:20.920 implemented called Dynamic Client Registration. 78 00:06:21.250 --> 00:06:28.150 And the idea there is the app first makes an API call to go get keys and then it uses 79 00:06:28.150 --> 00:06:29.770 those API keys in the rest of the flow. 80 00:06:30.130 --> 00:06:38.380 Now, that does nothing for the the level of assurance that the corporate API want of 81 00:06:38.530 --> 00:06:43.000 knowing who the developer is who has an app, but it does establish a client secret in a 82 00:06:43.000 --> 00:06:45.450 way that can be used in the rest of the flow. 83 00:06:45.790 --> 00:06:55.150 So it's not doing the app identity part, but it is doing the sort of API security aspect 84 00:06:55.150 --> 00:06:56.680 of client registration. 85 00:06:58.430 --> 00:07:03.650 The other way, which is what we've been doing in the IndieWeb community, is to avoid the 86 00:07:03.650 --> 00:07:09.920 need for registering at all because registration doesn't gain us any sort of identity 87 00:07:09.920 --> 00:07:13.910 proofing anyway. So if we avoid the need for registration, we need to have some sort of 88 00:07:13.910 --> 00:07:15.970 other identifier for the app. 89 00:07:15.980 --> 00:07:19.820 And it turns out that a URL is actually a fine identifier for applications. 90 00:07:20.120 --> 00:07:25.730 And then if we do use the URLs for identifiers of apps, we can also put app information 91 00:07:25.730 --> 00:07:31.670 at those URLs so we can actually then go get back to that identity confirmation of the 92 00:07:31.670 --> 00:07:33.580 app by using those URLs. 93 00:07:33.590 --> 00:07:36.950 And then the user knows like this is the app that's trying to log in because it's 94 00:07:37.220 --> 00:07:43.460 identified by the URL and you can show the app name and icon based on information at 95 00:07:43.460 --> 00:07:50.840 that URL. So that's the sort of main thing that I was talking about in the in the talk was 96 00:07:51.080 --> 00:07:55.400 to use URLs for these things because we avoid the need for that registration step. 97 00:07:55.580 --> 00:08:00.620 And that dynamic registration doesn't even really gain us anything in practice. 98 00:08:02.470 --> 00:08:09.110 So. I need to take a look at the chat, there's a bunch of stuff I haven't read. 99 00:08:12.370 --> 00:08:19.510 The -- where was I -- I was talking about, ok, can you give a little bit more detail into 100 00:08:19.510 --> 00:08:20.560 dynamic registration? 101 00:08:20.590 --> 00:08:24.010 Does this mean theoretically it wouldn't have to go through GitHub, Facebook register and 102 00:08:24.010 --> 00:08:28.000 process. So yeah the idea of dynamic client registration is that it's an API call to 103 00:08:28.000 --> 00:08:29.440 establish those credentials. 104 00:08:29.440 --> 00:08:33.670 However, you're not going to find that with stuff like GitHub and Google because they 105 00:08:33.670 --> 00:08:37.030 want the developer to have a relationship at that service. 106 00:08:37.570 --> 00:08:43.630 And at best, you actually you'll see references in dynamic client registration to adding 107 00:08:43.630 --> 00:08:47.920 authentication to the registration process, which 100% does not work in this environment, 108 00:08:47.920 --> 00:08:53.380 because that's assuming that you have some out-of-band authentication the app could use 109 00:08:53.380 --> 00:08:58.390 to then register new clients, which there's applications where that makes sense does not 110 00:08:58.390 --> 00:09:04.830 make sense here. So the dynamic client registration idea doesn't really make a lot of 111 00:09:04.830 --> 00:09:06.060 sense in this ecosystem. 112 00:09:07.530 --> 00:09:11.310 Chris says this is one of the big criticisms of OAuth 2 is that the secret makes no sense 113 00:09:11.310 --> 00:09:12.440 for open source applications. 114 00:09:12.450 --> 00:09:16.050 And you explain that it's not being required in the same way in 2.1, can you talk to the 115 00:09:16.050 --> 00:09:17.610 history of that and what it's been replaced with. 116 00:09:18.480 --> 00:09:26.980 So. There's a lot of criticisms of OAuth 2, fine, and the client secret was never required 117 00:09:26.990 --> 00:09:33.440 in OAuth 2, but a lot of the flows sort of need it in order for it to be secure until we 118 00:09:33.620 --> 00:09:34.720 realize that, 119 00:09:34.760 --> 00:09:39.110 well, JavaScript apps and mobile apps also can't use client secrets, regardless of whether 120 00:09:39.110 --> 00:09:43.570 they're open source. So the OAuth community had to come up with a solution. 121 00:09:43.580 --> 00:09:45.320 This was done years ago. 122 00:09:45.710 --> 00:09:50.240 But the solution for that was to create an extension called PKCE or proof for code 123 00:09:50.240 --> 00:09:51.740 exchange, P.K.C.E. 124 00:09:52.400 --> 00:10:01.000 And what that extension does is essentially it creates a per-request credential, secret 125 00:10:01.020 --> 00:10:05.160 of sorts, the client creates it when it starts to flow and it uses that throughout the 126 00:10:05.160 --> 00:10:09.390 one exchange and then it's done and then it's dropped and then it gets the access token 127 00:10:09.390 --> 00:10:15.510 at the end. So that is something that mobile apps and JavaScript apps use today in 128 00:10:15.510 --> 00:10:19.110 regular OAuth in corporate APIs, 129 00:10:20.310 --> 00:10:23.970 regardless of whether or not the app is open source, you just can't ship client secrets in 130 00:10:23.970 --> 00:10:25.350 these kinds of apps, so. 131 00:10:28.210 --> 00:10:34.150 That mechanism, it turns out, is a perfect way to also solve the fact that dynamic 132 00:10:34.350 --> 00:10:38.620 registration is kind of a weird thing to be doing in this ecosystem anyway, and that if 133 00:10:38.620 --> 00:10:44.830 we use the URLs for client IDs and use PKCE, we've then solved both aspects of that. 134 00:10:44.830 --> 00:10:49.210 We solved the identity confirmation of the app, and we've also solved the authentication 135 00:10:49.210 --> 00:10:50.470 part of that exchange. 136 00:10:54.450 --> 00:10:58.620 OK, jfred says, I guess it's sort of a general question, but if you use OAuth login in an 137 00:10:58.620 --> 00:11:01.640 app and the user enters their password into a webview of their servers login page. 138 00:11:01.650 --> 00:11:05.100 Doesn't the app still ultimately control that webview and can snoop on the user's login 139 00:11:05.100 --> 00:11:06.670 info? This is a very good question. 140 00:11:06.990 --> 00:11:15.060 So the the answer is if the application is using an embedded webview and some of the 141 00:11:15.060 --> 00:11:21.390 mobile platforms usually have a way to create a sort of web view in the app that the app 142 00:11:21.390 --> 00:11:25.510 has complete control over, and it can still load Web pages or load in HTML. 143 00:11:26.070 --> 00:11:31.410 That's actually not what we recommend for OAuth because of that exact reason, because of 144 00:11:31.410 --> 00:11:37.710 that exact reason of the app can look inside of that little window and snoop on the 145 00:11:37.710 --> 00:11:43.800 password. So do not use that for OAuth and don't embed a password dialog from a Web page 146 00:11:43.800 --> 00:11:45.660 in a web view -- that's not safe. 147 00:11:46.200 --> 00:11:52.530 Instead, the mobile platforms have specific APIs for doing these kinds of authentication 148 00:11:52.530 --> 00:11:59.670 flows. And what you'll see is you'll see a web browser like thing sort of pop up over the 149 00:11:59.670 --> 00:12:06.210 app and it'll be like out of the app's context so the app has no visibility into it. 150 00:12:06.210 --> 00:12:09.980 All the app can do is wait for the callback that runs when that window closes. 151 00:12:10.500 --> 00:12:14.640 So the app has no visibility into that window, which means it is safe to do things like 152 00:12:14.790 --> 00:12:21.030 password prompting. And because the app has no visibility, the that window will share 153 00:12:21.030 --> 00:12:24.990 cookies with the rest of the system browser so that if you are already logged into your 154 00:12:24.990 --> 00:12:30.780 server in your main, whether that's Safari on iOS or Chrome on Android, your main system 155 00:12:30.780 --> 00:12:36.810 browser, that cookie will be available to that embedded browser, which means you may not 156 00:12:36.810 --> 00:12:38.320 even have to type your password in, which is great. 157 00:12:38.880 --> 00:12:45.780 So that's the way to do to do an OAuth flow in a mobile app for both usability and the 158 00:12:45.780 --> 00:12:51.540 security aspect of it. Cool. 159 00:12:51.570 --> 00:12:56.410 So. Michael says the talk was great and really want to implement it. 160 00:12:56.590 --> 00:12:58.710 Thank you. Glad you enjoyed it. 161 00:13:02.590 --> 00:13:06.760 Ok, so Chris says, I have a big question. 162 00:13:08.040 --> 00:13:10.200 Might take up the rest of your Q&A, feel free to skip it. 163 00:13:10.230 --> 00:13:15.080 Ok, well, let me take a look at some of the other questions first, then hellekin says. 164 00:13:15.990 --> 00:13:17.290 Oh, I have a question for the end of the talk. 165 00:13:17.380 --> 00:13:18.510 Sure, I'll save it for the end. 166 00:13:19.480 --> 00:13:23.230 Teraku says, how far is implementation of these OAuth 2 additions? 167 00:13:23.740 --> 00:13:26.830 I think you mentioned IndieAuth in the talk, in the Fediverse or a more decentralized 168 00:13:26.830 --> 00:13:29.500 web. Every service provider has to ship their own authorization server. 169 00:13:29.530 --> 00:13:31.790 Is there some FOSS being actively developed? 170 00:13:32.080 --> 00:13:34.960 Great question. So they. 171 00:13:36.510 --> 00:13:41.520 There is there are quite a lot implementations of IndieAuth already, and some of that is 172 00:13:41.520 --> 00:13:44.290 done in individual pieces of software. 173 00:13:44.580 --> 00:13:47.180 So I've just built one into my own website. 174 00:13:47.970 --> 00:13:54.030 My website speaks a lot of the protocols like it is an activitypub server itself. 175 00:13:54.450 --> 00:13:58.740 It has a built in IndieAuth server and the -- 176 00:14:00.930 --> 00:14:04.950 So but yeah, so there's some some people have built their own. 177 00:14:05.130 --> 00:14:11.010 There's also a WordPress plugin that that adds an indieauth server into a WordPress blog, 178 00:14:11.220 --> 00:14:13.050 which is a great way to do that. 179 00:14:13.050 --> 00:14:16.770 Just turns your WordPress blog into a server. 180 00:14:16.830 --> 00:14:20.100 There's also, of course, the activitypub plugin for WordPress, so that's a great way to 181 00:14:20.100 --> 00:14:29.600 go. As for other platforms, I would like to see more like 182 00:14:29.780 --> 00:14:34.550 standalone authorization servers or products, because I do think that's -- 183 00:14:35.950 --> 00:14:41.500 it's just enough work to do that kind of thing well that it makes sense to have it be a 184 00:14:41.500 --> 00:14:42.700 sort of standalone component. 185 00:14:43.090 --> 00:14:48.850 You can imagine having your sort of OAuth server over here separate from your content 186 00:14:48.850 --> 00:14:50.860 management system, and then they can talk to each other. 187 00:14:51.730 --> 00:15:01.500 There are a couple of sort of mini scaled down versions of those 188 00:15:01.500 --> 00:15:05.340 right now, if you look at the IndieWeb wiki and just look for the indieauth article 189 00:15:05.340 --> 00:15:08.700 there, there's some links on there to some open source solutions for that. 190 00:15:08.730 --> 00:15:11.580 There's one that's like a single PHP file that you can drop in. 191 00:15:13.270 --> 00:15:17.420 But yeah, I would like to see like a more fully featured open source version. 192 00:15:17.700 --> 00:15:25.020 I am planning on building one myself still because I still need to replace my very first 193 00:15:25.020 --> 00:15:26.440 prototype of the one that's been running. 194 00:15:26.460 --> 00:15:29.430 So no idea when I'm going to get around to doing that. 195 00:15:29.430 --> 00:15:33.300 But at some point I will launch that and it will be open source as well. 196 00:15:33.540 --> 00:15:37.980 And I would actually rather have more people run their own copies of it than have been 197 00:15:37.980 --> 00:15:39.090 used. The one that I will be running. 198 00:15:41.880 --> 00:15:48.090 Ok, lanodan says, whatever whether you think, how did you get the final response, oh, 199 00:15:48.090 --> 00:15:53.760 yeah. So with that webview API in there is -- like when the app launches that window, the 200 00:15:53.760 --> 00:15:56.290 app has to register a callback method in the app. 201 00:15:56.640 --> 00:16:04.140 So basically what that means is when the window closes, the app will get the final URL of 202 00:16:04.470 --> 00:16:05.730 of that window. 203 00:16:06.090 --> 00:16:09.860 And that's where in OAuth you get the authorization code written in that redirect URL. 204 00:16:10.650 --> 00:16:13.650 So the app will be able to grab that URL. 205 00:16:13.650 --> 00:16:18.240 That is that final URL that the app -- that window launches. 206 00:16:18.240 --> 00:16:22.440 And then so there's no like effort required by the user in order to do that. 207 00:16:22.560 --> 00:16:26.400 So it's it's really just going to look like click log in, the thing slides up. 208 00:16:26.700 --> 00:16:27.840 You may already be logged in. 209 00:16:27.870 --> 00:16:31.440 You see the prompt you click allow, it goes away and the app is done and login. 210 00:16:34.830 --> 00:16:40.400 All right. Regarding standalone authorization servers, does Keycloak support IndieAuth 211 00:16:40.400 --> 00:16:44.720 what is missing in Keycloak. I don't think it does support IndieAuth right now, but it 212 00:16:44.720 --> 00:16:49.430 does support OAuth and I'm pretty sure it supports most of the best practices of OAuth 213 00:16:49.430 --> 00:16:54.050 that are part of the OAuth 2.1 roll-up. 214 00:16:54.440 --> 00:16:59.500 So adding IndieAuth to that would be not much work. 215 00:16:59.500 --> 00:17:08.330 It would require -- not requiring client registration, so accepting URLs as the client ID 216 00:17:08.550 --> 00:17:16.590 before the server already knows about that, URL, and it would require adding the specific 217 00:17:16.800 --> 00:17:20.400 response that identifies the user, because, again, OAuth doesn't actually talk about 218 00:17:20.430 --> 00:17:23.150 users, which is funny, does not talk about identifying users. 219 00:17:23.160 --> 00:17:24.510 There's no user ID in OAuth. 220 00:17:25.020 --> 00:17:31.830 So it would require adding the the user ID, the user's URL that you get after the OAuth, 221 00:17:31.830 --> 00:17:34.240 after the IndieAuth flow is complete into that. 222 00:17:34.240 --> 00:17:42.010 It would be a relatively -- excuse me -- a relatively little amount of work, and I would 223 00:17:42.010 --> 00:17:43.190 love to see that added to Keycloak. 224 00:17:43.210 --> 00:17:44.240 I think it's a great idea. 225 00:17:50.130 --> 00:17:54.570 All right, colby -- something to consider: OAuth delegates; example.github.io, is a 226 00:17:54.620 --> 00:17:58.650 static site implement OAuth -- correct -- but if it were annotated with a delegates and 227 00:17:58.650 --> 00:18:00.650 you could farm out some OAuth as a service provider. 228 00:18:00.930 --> 00:18:02.780 That is exactly how IndieAuth works. 229 00:18:03.040 --> 00:18:08.190 One hundred percent. So the way it works is you have your IndieAuth server set up 230 00:18:08.320 --> 00:18:12.470 somewhere and then at the profile URL you point to that server. 231 00:18:13.000 --> 00:18:20.560 So the first step that the client does is discovers the OAuth server for that user by 232 00:18:20.710 --> 00:18:24.850 asking them to enter their URL, doing discovery on that URL, finding the server and then 233 00:18:24.850 --> 00:18:29.080 using that server. So that's 100% possible to deploy on static sites. 234 00:18:29.090 --> 00:18:30.960 We have plenty of people doing that today. 235 00:18:31.360 --> 00:18:33.510 And that's great. 236 00:18:37.630 --> 00:18:42.110 Definitely take a look at the IndieAuth spec, if you're curious about reading up on that. 237 00:18:42.110 --> 00:18:43.390 Ok, I think I skipped a question. 238 00:18:48.830 --> 00:18:52.970 Schmittlauch says: when it came to building an API, the diaspora folks have been obsessed 239 00:18:52.970 --> 00:18:56.500 with OpenID Connect. Any idea why that looks like OAuth 2 on steroids? 240 00:18:56.510 --> 00:19:02.760 Plus authentication? I didn't realize Diaspora had been interested in OpenID Connect, I'm 241 00:19:02.760 --> 00:19:04.790 actually kind of surprised to hear that. 242 00:19:04.790 --> 00:19:09.090 OpenID Connect is definitely more in the enterprise space and like that's where you'll see 243 00:19:09.090 --> 00:19:12.170 it all over the place now, in those kinds of APIs. 244 00:19:12.190 --> 00:19:16.260 There is -- it does a lot of things. 245 00:19:16.500 --> 00:19:19.710 Chris says: tried to understand OpenID Connect and printed out about 100 pages of text, 246 00:19:19.710 --> 00:19:22.580 tried to find out what was core to understand, gave up. 247 00:19:23.070 --> 00:19:25.170 Yeah, there's a lot there. 248 00:19:25.170 --> 00:19:28.650 And it's because they're adding a lot of features they're doing -- they're adding a lot 249 00:19:28.650 --> 00:19:31.590 of features are useful in large scale environments. 250 00:19:31.590 --> 00:19:36.330 And that's why there's just so many documents and so many extensions. 251 00:19:37.220 --> 00:19:43.610 And those are like, there's plenty of uses for that scale of those things, but for what 252 00:19:43.610 --> 00:19:49.280 we're just talking about, in order to make these kinds of activitypub apps work, you 100% 253 00:19:49.280 --> 00:19:55.490 do not need any of that, because ultimately all you need from OpenID Connect is the 254 00:19:55.760 --> 00:20:00.980 addition of returning user IDs in order to make this work, because the app obviously is 255 00:20:00.980 --> 00:20:05.180 going to need to know who the user is or profile information for the user and that kind 256 00:20:05.180 --> 00:20:11.320 of thing. And OpenID Connect is a very roundabout, complicated way to get that data into 257 00:20:11.320 --> 00:20:15.910 and app, and it requires bringing in a JSON Web Token library and validating signatures 258 00:20:15.910 --> 00:20:17.240 and the list goes on. 259 00:20:17.650 --> 00:20:26.860 So OpenID Connect has a lot of features that are not needed for this kind of thing, which 260 00:20:26.860 --> 00:20:30.900 is why we wanted IndieAuth to be a lot simpler than that. 261 00:20:30.910 --> 00:20:32.570 So it adds a lot less stuff. 262 00:20:32.920 --> 00:20:36.310 Interestingly, IndieAuth and OpenID Connect were actually started at around the same 263 00:20:36.310 --> 00:20:44.970 time, despite despite OpenID Connect sort of being the thing you see everywhere. 264 00:20:44.970 --> 00:20:50.350 Ten minutes. Was that what you were going to say, Ok, I'm -- 265 00:20:53.980 --> 00:20:56.260 Let me take a look at the -- 266 00:20:57.560 --> 00:21:01.520 Chris's question, I'll talk a little bit about this, Chris. 267 00:21:02.030 --> 00:21:06.350 Chris says: as you hinted at this is just about the client to server API, but you had 268 00:21:06.350 --> 00:21:08.290 thoughts about OAuth and the server to server API. 269 00:21:08.300 --> 00:21:09.940 I have a feeling it's at least 30 minutes of material. 270 00:21:10.190 --> 00:21:12.800 Yeah, I could definitely talk a lot about that. 271 00:21:13.720 --> 00:21:21.640 This -- OAuth and IndieAuth are definitely more geared towards a client-to-server 272 00:21:21.700 --> 00:21:26.490 relationship. Server to server federation is a whole different -- the authentication for 273 00:21:26.490 --> 00:21:31.150 that is a whole different problem. We are trying to also do something in that space in the 274 00:21:31.300 --> 00:21:37.120 IndieWeb community as well, because as we're trying to do things like private feeds or 275 00:21:37.120 --> 00:21:41.710 private webmentions, private comments on blog posts, we want some way for someone's 276 00:21:41.710 --> 00:21:45.580 server to be able to fetch content that's private without a user being present. 277 00:21:45.970 --> 00:21:49.690 So we're trying to figure out a way to extend IndieAuth to 278 00:21:52.310 --> 00:22:00.500 work in a server to server environment, but it is a tricky problem and it's -- there's a 279 00:22:00.500 --> 00:22:04.420 lot of different considerations there and I haven't seen a good solution yet. 280 00:22:06.770 --> 00:22:10.280 We have -- yeah, by we in this case, I'm saying the IndieWeb community. 281 00:22:12.200 --> 00:22:17.830 We've got a couple of different iterations of various ways of doing that kind of spec, 282 00:22:18.080 --> 00:22:19.370 none of them have really stuck yet. 283 00:22:19.490 --> 00:22:22.670 And this is like -- this is how we try to treat spec development in the IndieWeb 284 00:22:22.670 --> 00:22:25.680 community. We brainstorm things, we try them out. 285 00:22:25.700 --> 00:22:30.350 We don't want to say -- we don't want to write something out and say this is how it's 286 00:22:30.350 --> 00:22:33.650 going to work and then force everybody to do it because that's not sustainable. 287 00:22:34.800 --> 00:22:39.770 What we are trying to do is brainstorm like, okay, what if we tried this and then get 288 00:22:39.770 --> 00:22:42.440 some people to actually build it to see if it's feasible. 289 00:22:42.950 --> 00:22:45.140 And then we learn stuff from that experience. 290 00:22:45.140 --> 00:22:52.710 And so far, what we've learned is that the previous attempts at this kind of API aren't 291 00:22:52.710 --> 00:22:54.310 -- we haven't figured it out yet. 292 00:22:54.560 --> 00:23:02.970 So, I do want to see that problem solved at some point as a extension of the OAuth work, 293 00:23:02.970 --> 00:23:06.900 because it does still come down to, like, a delegation idea, right. 294 00:23:06.900 --> 00:23:12.120 Where I'm going to be delegating some power to my server to be able to act as me in the 295 00:23:12.120 --> 00:23:15.240 network rather than delegating to an app to be able to act as me. 296 00:23:17.000 --> 00:23:22.960 Yeah, Chris, we should definitely talk about this, because it's super interesting and I 297 00:23:23.250 --> 00:23:29.270 want to find a solution that does not require building in cryptography into the protocol 298 00:23:29.270 --> 00:23:34.850 . I want to use cryptography as a transport the same way that we use HTTPS a transport 299 00:23:35.300 --> 00:23:40.220 rather than baking in crypto into the protocol because that's fragile and crypto changes. 300 00:23:40.580 --> 00:23:44.720 And I would like to swap transport layers without changing the protocol, which is what 301 00:23:44.720 --> 00:23:46.820 we've been doing with HTTPS for years. 302 00:23:46.970 --> 00:23:52.970 Right. We can change our TLS certificates as new methods come along we're up to TLS 1.3 303 00:23:53.840 --> 00:23:55.190 and whatever after that. 304 00:23:55.190 --> 00:24:00.230 And the different certs or different crypto methods within those can change. 305 00:24:00.470 --> 00:24:05.720 And none of the HTTP protocol layer has to change in order to just build on top of that 306 00:24:05.720 --> 00:24:11.240 transport. So that's the sort of philosophy that we're taking when we're we're talking 307 00:24:11.240 --> 00:24:17.780 about these. All right, so last question was -- 308 00:24:19.550 --> 00:24:24.200 The oh, yeah, my book, OAuth 2.0 Simplified. 309 00:24:24.200 --> 00:24:25.460 Is that still with all OAuth 2. 310 00:24:25.460 --> 00:24:27.110 1, or am I going to release a new one? 311 00:24:27.570 --> 00:24:30.040 I haven't decided if I'm going to release a new title. 312 00:24:30.290 --> 00:24:32.510 However, I have been updating that book. 313 00:24:32.720 --> 00:24:39.170 So that book was last updated in February and most of the OAuth 2.1 changes are actually 314 00:24:39.170 --> 00:24:42.400 not changes. This is what I was talking about the talk they're actually -- it's actually 315 00:24:42.410 --> 00:24:47.270 a consolidation. So I have been keeping the book up to date. 316 00:24:47.420 --> 00:24:54.830 And so if you if you have bought it since February, you have the latest version, but also 317 00:24:54.830 --> 00:24:57.170 the website, OAuth.com is the book. 318 00:24:57.440 --> 00:25:05.170 So this is, again, one of the reasons that OAuth 2.1 Is trying to be -- trying to do just 319 00:25:05.170 --> 00:25:10.600 the bare minimum in order to make things simpler because, yeah, I don't want to make 320 00:25:10.600 --> 00:25:12.440 everybody have to go and relearn everything. 321 00:25:12.460 --> 00:25:15.310 So instead, we're trying to just consolidate the information. 322 00:25:15.310 --> 00:25:19.450 And because of that it means the book is actually already mostly OAuth 2.1. 323 00:25:19.480 --> 00:25:24.940 It's describing that because it has been describing the best practices all along, which 324 00:25:24.940 --> 00:25:26.530 was the goal of the book in the first place. 325 00:25:28.820 --> 00:25:29.960 Cool. Well, thanks. 326 00:25:30.020 --> 00:25:32.120 Great discussion. Good questions. 327 00:25:32.990 --> 00:25:34.200 Thanks, everybody, for joining. 328 00:25:34.200 --> 00:25:37.330 I guess I'll end here. 329 00:25:37.340 --> 00:25:40.240 Wrap it up here and see you in the next session. 330 00:25:41.210 --> 00:25:44.640 MORGAN LEMMER WEBER: Thank you very much for your talk and your participation in the conference. 331 00:25:45.440 --> 00:25:45.860 AARON PARECKI: Thanks. 332 00:25:46.580 --> 00:25:48.680 MORGAN LEMMER WEBER: Ending the recording now.