Federating Access to IoT using OAuth
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32522 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Identity managementVideo gameRight angleWater vaporInsertion lossBitInformation securityCommunications protocolLecture/Conference
01:01
Information securityMessage passingMultiplication signInternetworkingParticle systemCommunications protocolDemo (music)Computer animation
01:41
Game controllerInternetworkingNumberSummierbarkeitIdentity managementInformation securityEmailScaling (geometry)Electronic mailing listModel theoryPasswordTouch typingInsertion lossPoint (geometry)FacebookInternet der DingeCentralizer and normalizerType theoryLecture/ConferenceComputer animation
03:09
Communications protocolPerspective (visual)Identity managementInternet der DingeGame controllerInternetworkingFacebookLecture/ConferenceComputer animation
04:23
Model theoryInternetworkingToken ringIdentity managementTelecommunicationRevision controlProcess (computing)PasswordInformation securityKey (cryptography)Formal languageGame controllerMultiplication signServer (computing)ImplementationInternet service providerCASE <Informatik>Workstation <Musikinstrument>Series (mathematics)DataflowPhysical systemSoftware frameworkCommunications protocolInsertion lossParticle systemSatelliteEmailStress (mechanics)Open sourceService-oriented architectureGroup actionProjective planeNumberWeb 2.0Slide ruleDemo (music)Different (Kate Ryan album)Client (computing)Graph (mathematics)Standard deviationNormal (geometry)FacebookAuthenticationJava appletQuicksortAuthorizationInternet der DingeLecture/Conference
08:54
Particle systemDataflowQuicksortDemo (music)Multiplication signMessage passingToken ringAxiom of choiceLevel (video gaming)NP-hardServer (computing)Service-oriented architectureEmbedded systemClient (computing)Quality of serviceLecture/ConferenceProgram flowchart
10:02
Library (computing)Process (computing)Physical systemInternet service providerToken ringSystem callDataflowComputer configurationComponent-based software engineeringRevision controlCuboidGodLecture/Conference
10:52
BitToken ringProcess (computing)Program flowchart
11:16
Multiplication signProcess (computing)Service-oriented architectureSystem callLecture/ConferenceProgram flowchart
11:37
Set (mathematics)Demo (music)BitHacker (term)Special unitary groupSystem callMechanism designOpen sourceBridging (networking)Standard deviationQuicksortOpen setServer (computing)Moment (mathematics)NumberPay televisionGame controllerRule of inferenceLecture/Conference
13:17
Standard deviationBitDemosceneQuicksortProgram flowchartLecture/Conference
13:47
Scripting languageWindowMultiplication signHeegaard splittingToken ringComputer animation
14:28
FacebookServer (computing)Process (computing)Public key certificateMobile appStatement (computer science)Lecture/Conference
15:17
Codierung <Programmierung>SpacetimeWaveString (computer science)GodQuicksortLecture/Conference
15:48
Token ringWater vaporDifferent (Kate Ryan album)RefractionDemo (music)Computer animation
16:14
Open sourceMusical ensembleResultantOcean currentService-oriented architectureScripting languageBitPoint (geometry)Connected spaceToken ringServer (computing)Information securityMereologyWindowData conversionCodeStandard deviationLeakClient (computing)Line (geometry)Cache (computing)Multiplication signSemiconductor memoryLecture/Conference
19:27
Communications protocolRoundness (object)DataflowBitDemo (music)Program flowchartLecture/Conference
20:24
Library (computing)Semiconductor memoryCodeInformation securityEncryptionToken ring
20:54
PasswordImplementationSet (mathematics)1 (number)Computer configurationTheory of relativityObservational studyDifferent (Kate Ryan album)Service-oriented architectureArmParticle systemSoftwareSuite (music)Insertion lossInformation securityModel theoryUniform boundedness principleMultiplication signClient (computing)MathematicsHierarchyMessage passingStandard ModelBitRight angleCommunications protocolCartesian coordinate systemConstraint (mathematics)Server (computing)EncryptionRule of inferenceTransport Layer SecurityEEPROMToken ringResolvent formalismInternet der DingeLecture/Conference
24:26
Multiplication signCommunications protocolFriction
25:01
Library (computing)Water vaporGame controllerProper mapBefehlsprozessorSemiconductor memoryCryptographyEllipseComputer configurationComputer hardwareControl flowAuthenticationChemical equationTransport Layer SecurityCasting (performing arts)GodBitLecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
00:06
I'd like to present my old friend Paul Fremantle who's going to talk about security on the intent of things. He's doing a PhD currently and is the CTO of WSO2. So Paul.
00:22
Thank you very much. Sorry, let me get my timer working. There we go. No, it's just failed. Never mind. I'll have to try and get it right. So hi, I'm Paul. And I'm a keen supporter of the concept of federated identity.
00:40
So who of you use OAuth or OAuth2? Excellent. Great. So that will make my life a lot easier today. So what I'm going to do is firstly just talk a little bit about federated identity access management. That's going to be very quick because a lot of you know about that. And a little bit about OAuth2. I'm going to talk very briefly about MQTT, which is a protocol I've been using.
01:03
It's a lightweight messaging protocol specifically designed around IoT, SCADA, that kind of devices. And then I'm going to put the two together, hopefully, with this Arduino. The demo has broken three times this morning already. So if it actually works, I will be very happy indeed.
01:21
You can buy me a beer afterwards. And then I'll talk about lessons learned and next steps. So federation is important. And it's very important for security because the big problem we've had with security and the internet has been centralized security where firstly people have failures, and secondly
01:42
it's not in your control. And especially as the number of users on the internet has grown massively, basically people have had to move to federated models. And that's why OAuth2 has been so popular. I see the same challenge with IoT devices, which is that there are billions of them
02:06
already. They're growing very rapidly. We can't expect them to use centralized traditional user ID password type security models that just aren't going to work and aren't going to scale particularly. And federated identity access management is really important because it allows you to retain
02:23
control of your password and user ID. Now unfortunately the way most people use this is that they give it to Facebook instead or Google and they trust them. And of course that itself is a challenge. But the point is that if you give it to someone who you do trust, then they don't
02:40
hand it out to anyone else. And this came about, OAuth came about specifically from problems like LinkedIn saying give me your Gmail user ID password. I'll go and grab your contact list and I promise not to send any emails, not to do anything else. And actually they're currently facing a lawsuit in the US saying that they did more than
03:01
they said they would. So OAuth2 basically says it's up to me to give a token or to authorize a token for LinkedIn to say how much they can access, what they can do, and how long that lasts. And that's also very important. And OAuth2 is a very, it seems to be the most used federated protocol.
03:24
It's used by GitHub, it's used by LinkedIn, Gmail, Facebook, and many, many others. So it seems to be a good approach at least to start using here. And really why federated in Identity Access Management for IoT?
03:42
Well, the most important thing from my perspective is it's your device, it ought to be your data. It ought to be under your control where you publish that data, who can access it, how they can access it. If my house is connected to the internet, maybe I want to let my neighbors check on
04:05
the health of it while I'm away, but only while I'm away. I don't want anybody else coming along and saying, hey, the lights haven't been on, nobody's been living there for a week, I'm going to go and burgle it. So it's very important that you can have control over your data.
04:21
And I think that's been a big failure in IoT devices so far because a lot of people haven't really thought about it. It's been a big failure on the internet overall, and it's something that we're slowly fixing. Another reason, a very technical reason, is that tokens are a much better model for managing identity in a device.
04:40
So most server-to-server communications these days, if they're designed properly, rely on tokens because a user ID password is for a person, not for a device. And another thing that depends on your OAuth implementation, but you can potentially manage the tokens and the scopes quite well. So you can embed that token in a device and then manage it over time.
05:05
So how do tokens work? Well, the basic idea is you get a token and you then pass just a token to the resource server. So there's two key parties here, the IDP, the identity provider, and the resource server. The resource server is what's trying to, you're trying to access resources on or you're always
05:26
trying to get access to your resources, and the IDP is the authentication server, in this case, or the authorization server. And so, as I said, OAuth 2.0 is very widely implemented. I think it's pretty good.
05:41
There are people who have criticisms, particularly over the concept of the bearer token, which is basically if you have this token, you have full control. So obviously, the stealing of bearer tokens is an issue, and that's a very big issue in IoT devices. I'll talk about that at the end. Of course, there's never any certainty with security protocols.
06:04
The only certainty is that it hasn't been broken yet. There is some researchers who've done a model of it using a framework from MIT called Alloy, and they've done some formal modeling of OAuth 2.0, so that gives you some more security. It isn't just used with HTTP. There is a draft spec for using it with SASL, so basically for allowing you to log on with SASL.
06:25
So it's getting some traction outside of HTTP. This is a three-legged OAuth. I'm going to sort of talk through this in the demo more, but I'll put these slides up on the web afterwards, and if you want more details, you can grab those.
06:42
So I'm also briefly going to talk about MQTT. Who's used MQTT before? Okay, a few of you, a few of the OAuth, that's interesting. So MQT, in fact, probably... Okay, so let me ask you a different question. Who's got Facebook Messenger on their phone? Okay, so more of you have used MQTT. You just didn't know it.
07:01
MQTT is a protocol that came out of IBM, but not out of one guy in IBM who happens not to be your typical IBMer, so it's not your normal IBM standard. It's very, very lightweight, very simple, and just does what it needs to.
07:21
And it was originally designed for a pipeline in Alaska. This pipeline monitoring guys came to IBM, and they said, well, we've got MQ series in our system, and we want to connect our monitoring stations on the pipeline to our MQ series system so we can follow the flow of the oil.
07:42
And so some IBM guy said, oh, well, that's okay. We'll just put MQ series on the monitoring stations. And they were like, well, there's a 1400-byte header with MQ series, and each extra byte costs us $78,000 a day because we're going through a satellite link. This was about 15 years ago, and it was very, very expensive.
08:03
So they were like, no, I don't think we can do that. So basically, they designed a protocol with a two-byte header. And the best thing that's happened to MQTT is it's recently... Really, a lot of it has moved to Eclipse. So there's a number of projects in Eclipse in the M2M group there
08:21
around creating open-source brokers. There's two C-based brokers, one called RSMB, one called Mosquito. A new one from Java is just about to be donated. Lots and lots of clients in different languages, and there's other clients and other things as well. It's also being standardized by Oasis. Some people have had bad experiences of that, but basically,
08:43
it's just gone through with some very minor clarifications and updates. So it's, I think, a pretty good process there. There's also a lighter-weight version for Zigbee called MQTT-SN. I'm not going to go into that, but that's actually a very nice protocol as well. Here's a sort of flow.
09:00
This is a full, reliable flow, which basically guarantees each message gets to each subscriber exactly once, which is why it's quite heavy. There's basically three qualities of service. You can say, no reliability. This message may or may not get there. It will definitely get there, but it may get there more than once. That's QoS 1. And this is, it will get there exactly once.
09:22
So that requires this sort of handshake. Now, the Arduino MQTT client can only do QoS 0, so there's no reliability there. But you can bridge that into a broker and then have the broker do higher levels of reliability when distributing the data. So, in my demo, what I'm going to do is I'm going to embed an OAuth token on here.
09:46
Now, actually, with tokens, there's two different things. There's the access token, which is known as the bearer token, and there's a refresh token. The access token typically times out. And so you normally have to go and say, well, when it's timed out, I'm going to go with my refresh token back to the server, the main IDP,
10:04
and get a new version of that token. Now, the problem is that's an HTTP call. Now, I don't have enough room on my Arduino for the HTTP and MQTT libraries and the actual job I want to do, which is I've got a little, you know,
10:22
accelerometer on here, and I want to publish information from that. So I have an I2C library talking to that. So what I did was I basically said, okay, well, one option would be basically to make an access token with a very, very long lifetime and embed that onto this thing. But that, firstly, is up to the OAuth provider you're providing.
10:43
So that's not necessarily going to work if you want to make this generic and work with any OAuth system. So what I did was I created a new component called the refresher, which are basically transferring that HTTP thing into an MQTT flow. So at the start, I'm going to pretend I've got an invalid bearer
11:01
token, and I'm going to try it. It's going to fail. So then I'm going to publish onto that, onto a different topic, a refresh token and get back the token I need. Then the Arduino is going to disconnect and reconnect with a new access token. So it's a little bit faked to demonstrate this process that normally would happen, you know, once a day or something,
11:21
but I'm going to make sure it happens every time. And then it's going to publish that to the broker, and the broker has a plug-in, I wrote in Python, which basically makes a call to something called the OAuth Introspection API, which is a RESTful call into the IDP to say,
11:42
what scope does this token have? The scope is basically the access control rule. And I encoded the scope as a bit of JSON, saying, you can read or write to this set of topics. So that's how I encoded the scoping here. So then the Arduino basically tries to publish a particular topic,
12:01
and the server is saying, does this user have, does this device have the credential? And then I also have a subscriber that's going to also use the same mechanism to get its subscription and basically pull data from it. Is that all clear? Any questions? It'll become a little bit clearer with the demo.
12:22
It's not a beautiful graphic demo like the first one. I was very impressed by that, but also rather shamed by mine, which is all a bunch of bad command line stuff. I'm using, all of this is open source. This bit is just a hack. Basically, there's an OAuth server here, which is from my company,
12:41
but it's pure Apache open source. There is a sort of a pseudo-standard introspection API for getting the scope from here, but we don't implement that yet. We're going to add it. So I have a, just, that was cool. I have something that's just transferring that. I could make the SOAP call into here that this offers,
13:03
but I don't really like SOAP, and I didn't want to have to do SOAP for my Python, so I bridged that into the standard call, and that's going to be in the next release of this server. So that's a sort of hack. But apart from that, and this API here is where number one is coming in is completely standard. That's specified by the OAuth spec.
13:21
Really, I think the OAuth spec should specify this one as well, and for some reason, the standardization of this in the ITF has kind of stalled a bit. I don't know why, because this is a useful API to say, give me a token now. Let me know what the lifetime of that token is, what the scope of it is, and so forth,
13:40
which is what this needs. And for some reason, that's sort of seen as behind the scenes by the OAuth guys. So because of the way this has failed so many times today, I'm going to actually bypass one of the steps, but I'm going to show you. I'm just now going to complete it. So the first step would be basically when you create your device.
14:02
So you need to push that refresh token into here. So the first thing I do is I go to a window here, and I have a little create token script.
14:24
And this basically just does a redirect to my IDP. So this is a redirect to the IDP saying, this is where the resource server says, this isn't my job. I'm going to hand you over to the OAuth server. So this is like when you go to Facebook and it says,
14:41
do you want to give this app permission to do this? And I don't have a SSL certificate on here, so it's basically saying it's not trusted. So then it says, now you have to log in and say who you are that's giving permission to this. So I put in my credentials, and I'm going to use this one.
15:01
Actually, no, I'm going to use this one. And bingo. And then it says, and then that scope should really be some meaningful statement. Do you want to allow this device to publish to your topic? Which should be what it's saying.
15:22
I've got it in a sort of, I've got a JSON string, and there was some problems with the way JSON's stored, because it's space delimited scopes in OAuth. So I base64 encoded my JSON. So it's not very useful, but it gives you the idea. So that obscure string gives permission
15:43
to publish to this particular topic. And then I'm going to, I'm hoping this isn't going to break the rest of the demo. So then I get some token, refresh and bearer tokens with a lifetime. They now have to be zapped into my Arduino.
16:00
I'm going to avoid that for the moment, and if it fails, then I'm going to try it again. So I'm hoping that that's why I used a different ID, because I'm hoping that I haven't overwritten the tokens and blown them out of the water. So I have some tokens already written in here. And then I would, and then basically, what's going to happen now is I'm going to pull up
16:22
one of my many windows, which has got my broker on it. So this is my Mosquito broker with the extra bit of code in it, and the extra bit of code signal is logging. And I've plugged in my Arduino, and it has, one second, let's see.
16:49
No, that's not right, give it a minute.
17:03
Let me just try it one more time. It was just somewhere else on the window. So what's happened here is that it's,
17:21
basically the Arduino has connected and has tried to connect with a dummy token, which is this 01234. So that's my expired bearer token. And it's failed. It got back a, you've got the wrong credentials. So now it's reconnected as with a,
17:44
really this should be connecting to a different broker at this point. This should be saying, I'm going to talk to my IDP and connect and get my, and refresh my token. I've kind of fudged it by having it on the same broker as the resource server. That's actually a big security hole,
18:01
but it's easily fixed. So then, it's now, there's a simple script here called refresher, which basically converts from MQTT to HTTP. So that takes that token and sends it to the IDP and says, here we go, swap this refresh token
18:21
for a new access token. That republishes it back onto MQTT, where the client picks it up, disconnects, and then it now reconnects with that token. And as you can see, I'm now getting some data from my accelerometer here.
18:40
And the whole thing dies a little bit because I haven't got any caching in here. So for every single publish it's doing, it's making HTTP call to my OAuth server. And it's a cruddy Python script running in the broker. And I have a feeling it's not garbage collecting properly
19:00
and there's some memory leak and it's not working. But because it's literally doing thousands and thousands of HTTP requests against this OAuth server straight away. That's easily fixed by firstly, getting someone who can actually write code to do it. And secondly, putting some caching in there, which is obvious. Because when you get back that scope from the introspection server,
19:21
if I just go back to my slides, when it gets this scope here, it gets a lifetime for that token. So it can then say, okay, I know that Paul's Arduino is authorized to publish for the next 60 minutes.
19:40
So now I can cache that here. So, okay, not the most exciting of demos. But I think what I've demonstrated here is firstly there are some tricky bits in using OAuth on such a small device. It's not the actual token that's easy, that's just a 30 or 40 byte character.
20:02
But the refresh little flow is a pain. Because you've got whatever your COAP or MQTT protocol and then suddenly you're meant to do an HTTP request over somewhere else. So by swapping it out and using the same protocol for both of those, I get around that.
20:22
Some interesting things here. So lessons learned. Well, my MQTT and I2C code took up 97% of the memory on my doing melanova. So I really didn't have room for the HTTP library as well. In fact, I had to cut out some of the I2C code
20:41
to actually get it all in. Another big issue is that it's a huge security flaw sending this refresh token and access token without some kind of encryption. So, and there's no TLS on this Arduino. So I think that's something that we need to solve
21:02
is how to do encryption on these Arduinos. It's a problem for anything. If I'm sending user ID and password, that's the same. So I don't feel it's any worse with OAuth, but it's certainly a problem that needs resolving. In this scenario, I would assume that I'm gonna have to have some local security to solve that,
21:20
or at least some kind of WiFi security if I'm using a WiFi network. One of the challenges here is that the OAuth implementations are all, they all follow the spec, but the spec has lots of little options. And when you're on such a small device, those little options matter. So for example, the refresh token can get changed
21:44
every time you use it, it can get changed. Now, I think that's a problem in a device like this, because there's no reliability. So it might send out a message saying, please change my refresh token. And then the network dies, or I go through a tunnel
22:03
or something, and I never get the new refresh token. And now the old one's dead. It's hard coded in the EEPROM here. I haven't had a chance to update it. Now how on earth do I get the new refresh token in here? So there are some challenges with different OAuth specs. And you need the right settings on those implementations to suit.
22:21
So I wanna make sure that I have a very long lifetime on my refresh token on this device, which might not be appropriate in a mobile phone where it's easy to get the person to log in and reset it, but on an embedded device that's hard. So I just hit that.
22:41
So I think the other thing is that some OAuth implementations let you update the spec, sorry, the scope for a token, but others don't. Just assume, okay, you want a different scope. You're gonna kill that token and do that login thing I showed you again. Of course, on an embedded device, that's not gonna work.
23:01
So for those devices, you need to be able to update the scope without changing the token. So I've got my device, it's in my house, and then suddenly I have a software update. It needs to do something different, publish to a different topic or a different target. I need to be able to update the scope without changing the token embedded on there.
23:21
And I told you this was a bit of a security flaw, the way that I had it all going through the resource server, which is my MQTT broker. Really, I should have had two brokers, but that's not a big deal. One of the other challenges is MQTT's really a pure PubSub model. So there's no well-defined way of saying,
23:42
I just wanna send this refresh token back to just this device. So what I did was I basically created a topic hierarchy slash clients and the client ID, and I implemented a custom security rule in my security add-on to say that only this device can subscribe to that topic.
24:02
So only this device is gonna get that data. But I feel that should at least be, I saw that there should be some kind of standard model for that in, maybe not in the spec itself, but in the kind of general way that people use MQTT. So the next steps, I wanna do the same thing for the constrained application protocol
24:22
or any other IoT protocols people want. Obviously, I need to fix my implementation. It did work, but only just. And I think there's that little flow with MQTT or with COAP ought to be defined in the same way that is for HTTP. Here's how you do a refresh on a different protocol.
24:42
If anyone's interested in this or has any other ideas on federated things that should be used with IoT, please contact me. I'm interested in collaborating. Or just contact me anyway. Thank you very much. Any questions?
25:00
We don't actually have time for questions. Maybe just one, one question. Go on. My watch says we got two minutes. What if you replace the Arduino with Arduino Uno or some device that actually can have memory and CPU for implementing TLS or proper authentication
25:22
instead of only Arduino? So I agree. I mean, I think that's important. But as far as I know, there's no TLS library for any Arduino. So I think that needs to be written. So if anyone wants to do that, please, please do that. That would be really useful. The other option would be something like,
25:40
there are some ECC elliptic cryptography chips that are very cheap. They're like 40, 50 cents, which would also probably allow you to do it on a really cheap device like this with an 8-bit controller. So I think it's a balance, isn't it? Do you do it in hardware with a shield?
26:01
And then it's sort of overtaken by improving CPUs. But on the other hand, those 8-bit controllers get cheaper and cheaper. And so the ability to have TLS on a really, really cheap device is also useful too. So there we go. We'll give you a complimentary bottle of water. All our speakers get that. Just call. Thank you very much.
26:23
So we have a five-minute break. And then we will talk on our next topic.