 At the back, okay? I start every presentation with two requests. First of all, if you can't hear me, ask me to speak up. Secondly, if I'm talking too quickly, tell me to slow down a lot because I tend to speak very quickly and I'll try and remember not to. But I will start as requested with a quick intro. So my name is, I don't even want my name on the screen. My name is Software Engineer and I am a Ben Decry. No, my name is Ben. I live in Melbourne, Australia. I love Singapore. I was here a couple of weeks ago. And I decided to come back again for another whole week just to meet the community because you're awesome. And I love having chats with you. So stick around afterwards and let's talk about security and not security, if you want. But I'm a Software Engineer. I've been programming in, actually started in ASP.VB. Does anybody remember that? God, you're old. I know I am. That was back in 1999. And then I very quickly got into PHP. And I've been doing that, or had been doing that for about 10, 15 years before I went more into the solutions architecture, security consulting side of things. I've done a fair amount of work with the community. I used to run conferences until I got Burnout. I have a lot of respect for people like Martin and Michael here who run conferences and meetups because it's a lot of hard work. So if there's one thing that I can ask you to do outside of this field of security, it's buy tickets to conferences, submit CFPs and support the local community when they create events like this. Because unless you come along, there's no point in running them. And the biggest way you can say thank you to any organizer for any event is just to be there most of the time. I'm a security and privacy nut. I keep telling people that I have intentions to put a silver foil hat under my scalp just to stop the government from being able to read my mind. I haven't done it yet. If anybody wants to test it out first and let me know if it hurts, I very much appreciate that. And these three kind of things that I love doing including implanting things in my head mean that I now work for Auth0 who are an identity in the cloud company. They basically do all the login and the password reset and the single sign on and the all the stuff that you shouldn't really have to care about which is why I'm here talking to you tonight actually is why you shouldn't have to care about these things. So why am I here tonight? What main things do I want to have a chat with you about? The main thing that I hear a lot is when you talk to people about how they've built and designed their software and you ask them about the security side of things they say, oh well it's grown organically which basically means we have no idea where it came from it just produced itself from the ground it grew like a tree, it went wherever it wanted leaves fell off, we raked it up it looks pretty but we don't know whether it actually works. Next year it might be dead. If you give me a plan next year it will be dead. So our security has developed organically. Then I want to find out how can we actually do it better? What is the next step after your because often we build software so quickly we don't have time to keep up with the security side of things. So what's a better way of doing that? And then finally how can we just not care? So let's start at the beginning. We all know what our website is and how our website works. Does anybody here not know what HTTP is? We're on a good start. So in the beginning you had some kind of user with their web browser and they head off to some server over there I don't know it's Google or Facebook or whatever you want. We connect via this magic called the cloud. We all love the cloud. So we connect through this cloud we make a request to the server and say I want to get some kind of resource from you. So web page or it's an image or something. And the server then says well I don't actually know who you are yet. So I'm going to show you a login page you can then put your username and password in send that back to me. I'm then going to go off to my database and see whether or not I can get that username and password combination. And if I can that result will then be sent back to me and I can then give you a check mark and say yes you're logged in. And now I will give you whatever it was that you were requesting. So we're all familiar with that kind of login mechanism. So let's take a step back or forward a year. And you've had this running for a while and you're maintaining it from day to day and you're adding extra functionality. And then your manager comes along and they says we need to scale. Our servers are getting hit harder. We're not able to store enough data. We need to spread the databases out. We need some kind of load balancing of the servers. So you put in three extra servers and another database. This is where the fun starts. So each of those servers is now going to have to be able to talk to one of the databases to check to see if the username and password is correct. Meanwhile, the two databases are going to have to continuously synchronize because you might be changing passwords or adding users or deleting users or just disabling them. Because you've now got four servers that you could be hitting, you can't rely on local session storage. You have to have some kind of external centralized session maintenance like Memcache or something. So you've got an extra server at the top there and that itself might need to be scaled in the future. So they're all talking to Memcache. And then meanwhile you think to yourself well there's a whole lot of functionality we've got here that we can actually start moving towards a service oriented environment and we'll put an API in at the bottom. So now you've got these machines talking to an API and a machine to machine format. So you're going to need to be able to get the API to talk to the database to work out whether or not the machine is allowed to talk to it. You've got the API keys and your client IDs and the secrets and such. And then somebody says, well, you know, if we've got an API, why can't we just get the web server to talk directly to the API, directly to the API. And now we can use XML HTTP requests to get more dynamic user interface user experience which will make our customers happier. So now the API needs a second connection to the database to work out who's actually logged in to work out what they're allowed to do because the API is now acting on users requests as well as machines requests. And then somebody says, well, I don't know why we've got these two databases of users in here because we've got an active directory store already and we've got all of our users in active directory. So can we just link active directory so all the servers will allow an active directory user to log in which means that we also need to synchronize that with the API. So the API knows which active directory user is using it. And we're also going to have to synchronize with that with the database because we've already got users in the database and we need to link those between the active directory users and the databases. And then somebody says, well, we've got this API down here. Why don't we create a mobile app which will also talk to the API. Just got really complicated. And that's when you look at it just a few simple requests really. We need to scale. We'd like more responsive user experience. Need a mobile app. We want to link our active directory users in. When you look at it as a top level for items, most people would say, oh yeah, well we can break that down and we'll follow our trial. We'll create some stories and we'll work on it. But when you plan it out, that's probably months, if not years worth of work. And this here is all just the authentication and user management. I haven't even talked about data between the applications for them to actually do the business logic of whatever it is that your product provides. Hands up if you work in software engineering and work for a company that provides any kind of service to customers. Any service at all. If you're a software engineer and you're employed, that should be all hands up. How many people in this room work for a company whose sole job is to create a login form? If you change your login form, are your customers going to be any happier? You might be a bit more secure but are your customers going to be any happier? Probably not. There are very few companies in the world whose sole job is to create login forms and to do a single sign on, like that's their job and that's people like Auth0 or Cognito or Octa. And these lines here are only for the authentication. Once you've got the authentication done, that's when you can start looking at the model of how do I transfer data that's actually usable by our clients. So all of this complexity is not even helping your clients get a better product. So how can we do it better? There must be a better way of doing it. Let's have a look at this bit over here. That's where the mess is on the right-hand side there. So let's get rid of all of that and replace it with an identity server. This can be off-the-shelf key cloak that you can run it yourself. I can't remember what technology key cloak's on. Is it Java, I think? But it doesn't matter. You can be a Python developer. You can be a PHP developer. You can be a .NET developer. Because identity providers are platform agnostic, you can run that in another system and through the magic of JSON Web tokens and OpenID Connect and OAuth, it doesn't matter what language it's in. And you can just install that and run it within your own system. You'd still need to maintain that. The other option is you go to a cloud service and you get them to run it for you. But you centralize all of the identity stuff in the middle. So we can immediately get rid of the login line there. That line that just fell down was me logging into the server because we're now gonna log directly into the identity server. The identity server is now the only system that knows my password. We don't need multiple passwords in the database. We don't ever need to send our password directly to the server, to our server, our business logic server. We only ever send it to the identity server, which is either controlled by us or somebody else. We don't care at this point. Once that happens, the identity server can then talk back to the main application server to give more information about the identity of the person who's just logged in. And it can provide the same information to the API. They can even synchronize users between itself and a database because obviously you're going to need to associate your business data with your clients, even though they've logged into a third-party system. You're still holding their financial information if you're a financial data aggregator, or you're still storing all their messages if you're an online messaging chat system. Whatever the actual value that you provide your clients, you still have to know who your clients are and what data you have, but you don't need to know their identity. You just need to have that link between who's just logged in and what data belongs to them. You can synchronize that directly through SSO or third-party connection to any kind of active directory. So if you're using Azure AD or whatever the Amazon one is, I can't remember what it's called right now. Any of the active directory services, you can link straight into most of the identity providers. You don't have to worry about that. There's a link that works there already. So now when somebody starts working at your company and you add them into your local company directory, they automatically have an account on all of your systems already. So let's have a quick look at how the OAuth OpenID process works, just so you get a bit of an understanding of why this works, why it's more secure and where the data flows. So we started before with the user logs into a server and gets redirected to a login page. So in this case, the user logs into the server. The server over here has two extra bits of information. At the top there, the little person in the circle, that's the client identifier, and the other one is the client secret. So when I say client at this point, I'm also gonna move around which is really gonna annoy the person on the camera. So when I say client, the application that you're writing is the client of the identity provider. Got a provider and a client. And then over here, I'll refer to this as the browser as opposed to the client. So we have the person with the browser. We've got the identity client, the identity provider. So the application you write will have this pair, the identity, the client ID, which is potentially public information. There's nothing secretive about it. You can share that with anybody. And then you've got the secret, which is the secret. So I come in and I'll log in and what it does rather than redirect me to a login page is it sends me a response with the client ID and redirects me to the identity provider. So the identity provider now has this client ID which identifies the client. So it can do things like render the login form with your logo. It knows which database to look at for your users because obviously you don't want somebody, if you're using Auth0, you don't want somebody from a different tenant to be able to log in to your application. So it just gives it information about which sets of users can log in and how they can log in. It'll then redirect you to a login page that's hosted by the identity provider. So now all of a sudden, because it's hosted in a more secure environment, you don't have to worry so much about things like cross-site injection and various other attacks that could happen through JavaScript. When the login, when the credentials are sent, they're sent straight back to the identity server, not the client, not your server. The identity server will then look up in its database and find that it is in fact a user. So it creates an access and authorization code and I'll send the authorization code back to the browser. The reason it sends it back to the browser is because the browser needs to tell the server what the authorization code is. So the server has that session connection for it. So when that token gets sent, when the access code gets sent back to the server, the server can now, all it's got is this code and it's probably about that long. I don't know what font size, but it's about that long. It's just gobbledygook. It doesn't make any sense and it doesn't mean anything to anybody. But if you take that access token and the secret, when you send that down to the identity provider in a machine-to-machine back channel, so that's over TLS, it's secure. There's very little chance of an HTTP or of a man in the middle attack. So those two bits of information go down. The identity provider can now say, yes, I remember issuing that code to Ben who was for this client ID and the secret you just sent me matches that client ID secret combination. So what I'm going to do now is I'm going to generate a JSON web token and I'm going to send that back to the server. So there's a lot of moving parts in there, but from the browser's perspective, it looked no different. They requested login. They were shown a login screen. They submitted it. And then even though there's a couple of extra backs and forwards, eventually it's going to get the rendered screen. The advantage now is that your application has an access token, which basically allows you to talk to any other APIs that are part of your ecosystem. As that user, you've got that identity wrapped up in the token, but you'd never know my username and password. So we've taken that off your hands altogether. So this is what it looks like drawn out again. The other thing that's changed is that the credentials are now only sent to the identity provider. So I've mentioned before that that increases your security. The tokens are generated by the identity provider can be shared within the ecosystem of your applications with any of your, if you're looking at a service oriented architecture, any of your services, you can use it to talk to any systems that can consume JSON web tokens. And that doesn't even need to be a web application. One proof of concept that I've been working on is actually using a JSON web token to unlock a door, where the door doesn't have any internet connectivity. It's just got an NFC reader. So I write the JSON web token on to an NFC card and I touch that on the door and the door unlocks. So because the JSON web token is a self-contained package, it's got a header, it's got a payload which contains all the information like who's logged in, what their email address is, what their name is, and it's got a signature to verify that the data hasn't been modified. You can actually consume a JSON web token in a completely isolated environment with no internet connection and still be sure that the token is valid, which is a really nice extra benefit. The token can be used directly between your web application and your databases as well. It doesn't even need to go via the identity provider or via the browser. And yeah, as I said, the credentials can also, because they all go to the IDP, the mobile phone app can now also log directly into the identity provider. And you've got that single point, the token comes back and now the mobile app can use the token that it's received to talk to the API. So suddenly the mobile app isn't sending the username, password to anything other than the identity provider either. So that bit there essentially is the bit you shouldn't care about. So I mentioned before I was asking what kind of companies you work for and whether or not you write software that is just a login form. Every day as software developers, we should really have two jobs, fixing bugs because there's no such thing as bug free code. Anybody written bug free code? I'm lying, anybody else? And the other one is feature development. Creating new features for our users. If we're spending time making, Hands Up who's written their own PCI compliant credit card processing code? Okay, now Hands Up who's used Stripe? Okay, two, three, four Hands Up, zero for the first one. Anybody who's ever done any kind of credit card payment processing, 99% of the time you're going to use a third party. You're going to use a cloud service to do that. And yet every day we still write a new login form. And then we've got a login form that we've got to maintain. We've got a password reset form we've got to maintain. We have to make sure we're using the right hashing algorithm. When hashing becomes like 10 years ago we used MD5 for hashing passwords. You would never do that nowadays. But some people still do because the code is still there so you've got to maintain that code. So if you concentrate just on the bugs and the features that will help your business, help your clients more, then you're obviously going to do a better job. Your company's going to do a better job for your clients. You're going to do a better job for your company. Everyone's going to be happier. You might even get a pay rise. I don't know, I'm not making any promises. Come talk to me afterwards. Maybe I can help you out. Actually, I probably can't. But there's a whole lot of things that we've started outsourcing and identity should be one of those as well because there are companies who are solely dedicated to making sure that your client's credentials aren't leaked. So that's pretty much it. Oh, there's an extra. So yes, the credentials and the tokens and everything. That's pretty much it. I'd love to take any questions either now or afterwards. I'll be hanging around all evening until I get kicked out. If you do have any, please go ahead now. Thank you for your time. Questions? I love it when I explain everything so well that I'm... Oh, there is one. Damn. Have you ever filled it or government and so on? Have I ever implemented identity service for governments? So Auth0 specifically, you mean? I personally haven't. I've never written on an identity server, mainly because you'd have to be crazy to actually write an identity server. So I leave it to the crazy people to actually write an identity server. Auth0 does actually work with one of the Brisbane, the Queensland governments in Australia. I think they might be talking to somebody in Singapore. We do a lot of work with governments and councils across America as well. So it's definitely something that happens. The one thing that I found personally when governments ask for help around security and the kind of thing is they're very particular on data sovereignty. So where is the data gonna be stored and how is the transmitter between the user? So as an example, I'm not saying this is the case. I don't know what the conversation is with the Singaporean government, if any. But if there was a conversation, they would probably want to make sure that any data that Auth0 stores is in Singapore and anytime somebody in Singapore logs in, it only ever gets sent to a server in Singapore and it never leaves Singaporean sovereignty. Yeah, pauses. And that's something that Auth0 can do. Awesome, well, thank you very much. Okay, yeah, I mean, you will still be here, right? So after the second talk, we will probably have half an hour still to finish the pizza and you can still approach Ben afterwards if you have more questions, right? I promise not to finish all the pizza while the next talk is on.