 Thanks. Well, thank you very much. OK. So thanks for coming this evening to hear me talk. My talk is titled, Securing APIs with Authentication and Authorization. But if you read the description, you'll probably realize there's a lot more content than just that. We're going to talk about privacy, data reaches, and things like that. Floris, I just want to check. Can everyone hear me OK? Can I get the back to you here, OK? Yeah? OK, great. OK, about me, I'm Dave Garvey. I'm technical director at Tyche here in Singapore. We're covering the APAC region. Tyche is an API management platform. So it comes with API gateway, management dashboard, developer portal. And its purpose is to let you easily manage your APIs, do things like protect them, secure them, publish and document, as well as providing developer self service to the portal and support microservice architectures and so on. And we have offices in London and Singapore and staff who work throughout the world remotely. OK, so let's get on with the talk. Today, I'm going to cover the topics of privacy, regulations, data breaches, security, and how these relate to APIs. And we'll also take a look at how you can use OL2 to gain consent from an individual to access their data. And also demo octa as well. It's not on there. And then hopefully, we'll have time at the end for some Q&As as well. And I'll be around afterwards. So if you want to ask me any questions, please do. So what is privacy? Let's start with a definition from Wikipedia. It says, privacy is the ability of an individual group to seclude themselves or information about themselves and thereby express themselves selectively. Prior to the advent of digital services, the idea of privacy was quite simple. If you post a letter to somebody, you'd expect that only that person would read it. If you write a diary, you'd expect that it's for your eyes only. If you make a phone call, you'd hope that the government hadn't bugged your phone. But time moves on. And in today's digital world, we may have the same expectations. But the digital world is much different to the real world. Once your data has been consumed by digital systems, it can be copied, transformed, and transported across the world and analyzed in the blink of an eye. Data can also be collected passively without you even noticing. As digital services have evolved over time, they've become more sophisticated and intertwined with our personal lives. Let's take a look at some examples. Starting with email. This was one of the first digital services which had a personal aspect to it. It wasn't long before providers figured out that the contents of your emails might provide them with some insights about your lifestyle and could therefore use this information to display relevant adverts. Though just last year at Google's day-to-day stop doing this, instead they just based their ads on the profile they've already built about you. Then came social media. Have you ever wondered why social media platforms encourage you to share so much? Your age, your location, your favorite music, where you like to go on a holiday, whether you have any pets, locations that you check into, the demographics of your friends and perhaps even your political persuasions is because it allows them to offer a very targeted advertising. What you post on these platforms can be used to calculate your likes and dislikes and it allows them to gather huge amounts of data on people, the likes of which have not been seen before. And in recent years, smart speakers have become increasingly popular. Driven by voice commands, they are constantly listening. It sounds a bit like the telescreens from George Orwell's 1984. There was a case reported recently of Amazon Echo recording a private conversation and sending it to a random contact in that person's phone. She's quite worried, but I wasn't said that it was just an extremely rare occurrence, so that's okay. The business models of many of the most common popular digital services are based on their relationships with advertisers and other organizations who benefit from understanding what people want, such as political think tanks. How do you think that they can offer these services to? Basically, your data is their product. There we go. I wanted to use this picture. Been meaning to for a while. Yeah. Okay, so, rural technology are very different when it comes to how quickly they move. Laws and regulations typically take many months, if not years, to agree and enact. Whereas technology, especially digital services, can change much quicker. So, it's not a surprise that it's taken a while for substantial rules and regulations to come into effect. Many laws have been passed which aim to prevent organizations from misusing personal data and to enable individuals to understand and control the personal data which is held about them. Let's take a quick look at two of the most relevant, GDPR and PDPA. GDPR came to effect on the 25th of May this year. The acronym stands for General Data Protection Regulation and it was initially proposed all the way back in 2012, so that just shows you how long it takes for these laws to come into effect. It's an EU law, so it covers all individuals within the European Union and it also addresses the export of data outside of the EU. So, even if you are based outside the EU as we are here, if you're managing EU citizen data, then you have to comply with this regulation. That's why it's relevant. GDPR follows the principle of data protection by design and by default and aims to empower the individual, enabling them to access and erase data relating to themselves. When the law came into effect earlier this year, Google received 2.4 million requests to delete search results. Businesses which violate GDPR can be fined up to 20 million euros or 4% of their annual worldwide turnover, whichever is higher. So, make sure you're complying. Then we have PDPA, which stands for the Personal Data Protection Act. It can be seen as a Singaporean variant of GDPR and it's a law that governs the collection use and disclosure of personal data by all private organizations. The Act came into full effect on the 2nd of July, 2014. When compared with GDPR, PDPA is more about getting businesses to adopt best practices and establish a culture of privacy. The aim is for businesses to have management programs which cover the collection, storage, use, disclosure, archival and disposal of personal data. Businesses found to be violating this regulation can be fined up to 1 million Singapore dollars. So how should we deal with these regulations? So you need to understand your obligations, both in the territories you're located in and those of the individuals whose data you collect. If you're exposing personal data you've collected, don't walk into that situation blind. Know that who you're sharing with and what they're gonna do with it because you can actually be liable for any misuse. Also, only ask for data which is needed. You may have heard recently about the ruling in Singapore about the collection of NRIC numbers which is now illegal unless there is an official reason to do so. Businesses which have already collected NRIC numbers and decide they want to keep them, they can do so but they must ensure adequate protection is in place including the anonymization of the data. The Personal Data Protection Commission who are the body responsible for the regulation released a statement regarding this law which they said in today's digital economy, indiscriminate collection or negligent handling of NRIC numbers can increase the risk of unintended disclosure and may result in NRIC numbers being used for illegal activities such as identity theft or fraud. This raises the subject of unintended disclosure aka hacking or data breaches. So Wikipedia, again I'm using them to define this, they define the data breach as an intentional or unintentional release of secure or private slash confidential information to an untrusted environment. I think another good way of describing it is as a security incident in which sensitive, protected or confidential data is copy transmitted, used, stolen or used by an individual on authorized to do so. This can include data such as credit card or bank details, personal health information, personally identifiable information, passwords and other credentials which are especially valuable when they combine with email addresses due to the fact that a lot of people reuse credentials across sites and also trade secrets and intellectual property. There's been several high profile incidents just in the last year. So you've probably heard of the Facebook, Cambridge Analytica scandal which was estimated to affect 87 million people's personal data. Then there was Under Armour and my fitness pal who had 150 million accounts hacked whereby the user names, emails and hash passwords were leaked. And just recently, Sing Health had 1.5 million accounts where the personal health data was leaked. And British Airways had 380,000 accounts whereby the full bank details were leaked. Though these seem quite small really compared to in 2018 when the data breach there affected an estimated three billion accounts. So the consequences of a data breach where an organization can both be based on their reputation and finances. So they can have things such as fines imposed by regulators. They can have lots of credibility for their brand. And even things like a reduction in the value of the company stock. And something I saw on Twitter at the weekend which amused me was an outage of chicken wings caused by a recent cyber attack. So that was unusual but there you go. It can have all sorts of effects. So we're at an API meetup. So how does this apply to APIs? Well, data breaches come in many forms including APIs. This year a company called Panero Bread a North American cafe chain had an unauthenticated API endpoint exposed via their website. This endpoint gave access to customer information including the customer's username, email address, date of their phone number and so on. This led to 37 million records of customer data being leaked over an eight month period. So what approaches can be taken to prevent such breaches in the Panero Bread case requiring the API request to authenticate would have been a good start. Then beyond that authorizing request as well and also not storing personal data in the first place they can avoid it. When we talk about limiting access to servers and APIs authentication and authorization are often discussed together. They define who you are and what you're able to do. So authentication being the process through which a client proves their identity to the server and authorization is the server controlling the actions of the client. So in the synopsis of this presentation one of the questions was when to apply authentication and authorization to your API? Well, the answer is almost always. If you can truly say that you don't need to know who is accessing your API then perhaps you don't need authentication. Perhaps your API provides access to freely available data so you don't need authentication, right? Well, I'd still argue not really because customers can negatively affect your API whether it's intentional or not. Consider the noisy neighbor problem where the performance of your API is degraded because one particular user has written some bad code and it calls your API a thousand times a second. This consumes all of your server processing power slowing your API to a crawl and leaving everyone with a poor experience. In this scenario, if you had authenticated the user it would have allowed you to identify the culprits and apply measures such as rate limiting to prevent this sort of thing from happening in the first place. So with regular data breaches and increasing regulation it's no surprise that there are a variety of solutions available. The rapidly emerging regulation technology market also known as RegTech is a field which the financial services industry utilizes to help them manage personal data and enhance their regulatory processes. It puts a particular emphasis on regulatory monitoring and thus it's benefiting themselves. So these RegTech applications are software which provide management and privacy compliance that aims to transform how businesses collect, maintain and use customer data. They're basically offering compliance software as a service helping organizations meet their data protection obligations. Alongside this is the identity provider market which is also known in the finance industry as KYC which is Know Your Customer. KYC is what businesses do in order to verify identity of their clients either before or during the time that they're doing business. This market is already very large. It's estimated by loginradius.com to be worth 18.3 billion US dollars by next year. And when compared to RegTech identity providers are more focused on providing identity services such as authentication, single sign-on and multi-factor authentication rather than compliance and privacy regulations. But I think that the two can combine together to satisfy both privacy and security needs. So there's many options available for API authentication. It can be quite difficult to choose the right approach for your API. So here's some general points which can help you decide. If you're in a regulated industry such as banking then the regulations may stipulate that you adhere to particular security standards. If so, make sure that you're following these regulations and are sufficiently tested to ensure that you're complying with them correctly. Also think from the consumer's perspective how are you expecting them to interact with your API? If it's via a website then you may need to support an interactive authentication workflow. But if it's machine-to-machine interaction then you should take a different approach. Also try to be consistent across your APIs. It's not ideal for consumers to have different authentication methods depending on which part of the API they want you to call. So let's have a look at some of the options out there in a bit more detail. So the first one, username and password. Well, it's good old username and password. It's the grandfather of authentication techniques. I think the pros for this are that it's quick and easy. So everybody is familiar with a username and password so it's not too difficult for them. The cons are that it can be guessed. Quite often these things are guessed, both email addresses and password. They don't contain any payloads so there's no metadata in them. Also if you're using username and password you really should be storing them very securely because if that data is leaked then it's very dangerous. Also they don't support sophisticated workflows such as resets and so on as other methods do so they're quite simplistic. So I'd suggest using these when familiarity is important and perhaps you want to make use of existing credentials that you already have to make your users' lives easier. Next we have all token, also known as an API key. An all token is a randomly generated string. Not too different to a long random password really which means that it's pretty much the same in terms of the pros and cons so it's easy to use. Although it is more difficult to guess than a password so I'm saying it's more secure. And the other benefit is that it doesn't contain any personal data because it's just random so that's good as well. But it has the same cons so no payload, no workflows at all really. So I'd say use it when you want a more robust alternative to user names and passwords or when you want to prioritize simplicity. So I often use API keys when I'm demoing software because it's just so simple. Then we move on to Oof 2. So this is an industry standard for authorization. The pros here are that it offers a variety of different approaches to suit your needs. Also, because it uses delegation, it means you don't have to store any sensitive data yourself. And also you can gain authorization from the resource owner to access their data so it's useful for that and we'll see that in the demos later. And lastly, it's very widely supported. There's plenty of providers who support Oof 2. I think in the cons for this, well, it's officially its authorization standard so it has to be combined with an authentication service as well in order to sort of offer the full result that people are looking for when they're authenticating against an API. But that's not such a problem because a lot of providers mix the two together for you so it will work out the box. Other than that, I think it's been superseded somewhat by other technologies. It's coming for its fair share of criticism as well. If you Google, you'll find plenty of it. So I'd say to use this when you want a third party to deal with identity, so that's quite compelling. And you'd also want to use it when you want the consumer to authorize access to their account data as well. And perhaps also you want flexibility in implementation because it supports so many different approaches. So let's look at some of those different approaches now. This diagram is from octa.com. So I'll be showing you octa later. So they have a great article about Oof and choosing the right flows. Because it offers so many different flows, it can be hard to figure out which is the most suitable for your situation. So this diagram helps you figure out by giving you a yes-no, basic yes-no. So the first question is, is your client public? So a client application is considered public when an end user could potentially view or modify the code. So this includes things like single page applications, any mobile or native applications as well. In both cases, the application cannot keep secrets from malicious users. So they would count as public. So if you went over to the left-hand side, the next question is, is your client a single page application or a native app? If your client application is a single page application, then you should use the implicit flow. If it's not, then you should use authorization code with PKTE. Then we move over to the right. The question there is, does the client have an end user? So if your client application is running on a server with no direct end user, then it can be trusted to store credentials and use them responsibly. If your client application will only be doing machine-to-machine interaction, then you should be using the client credentials flow on the right. And the last question is, does the resource owner own the client? So if you own both the client application and the resource that it's accessing, then your application can be trusted to store your end user's login. But because of the high degree of trust required here, you should only use this flow if the other flows are not viable. In this case, you could use the resource owner password flow. Otherwise, we'll be using authorization code flow, which is what we'll be using later on. In the same article, the Furlham page, they also have all these sequence diagrams. So it's really helpful for understanding what the flows are for each of the different flows. This flow here is the authorization code flow, which is what I'll be demonstrating. So the authorization code flow is best used by server-side apps where the source code's not publicly exposed. The app should be server-side because the request that exchanges the authorization code for a token requires a client's secrets, which will have to be stored in the client. The server-side app requires an end user, however, because it relies on interaction with the end user's browser, which will redirect the user and receive the authorization code. But the important thing, I think, to notice in the context of this talk, because we were also talking about consent as well, is that around over here, we have this option that says authentication and consent. So when the original client acts the authorization server, it will pass over some claims that it wants to make on the data. And so the user will see what those claims are, and if they consent to them, then everything carries on down the sequence. Otherwise, they would stop there. So that's how you can get a user to consent to accessing their data off a particular platform. So for example, with GitHub, I'm going to be using GitHub's Oof client later, you can pass all sorts of claims over, such as I would like access to your repos and can I write and things like that. But there's a whole set of them you can find. On any Oof provider, they will provide you with all the different claims that they offer. Okay, so next option in terms of Oof is OpenID Connect. So this is basically the missing identity layer to Oof 2. And when I was talking about Oof 2 being superseded, this is the technology I'm referring to. So it handles authentication natively. It was built to be API friendly based on criticisms which Oof 2 received. And it uses delegation like Oof 2. There's no need to store the sensitive data in your own application. You can store it in the identity server. The cons, I think, I mean, if you were to try and implement it yourself, it would be quite difficult, I'd say. But luckily, it's not much of a con because basically everyone would, I think, would use either identity provider or they'd use some sort of software they could install on their own infrastructure which would handle this process for them rather than trying to implement it themselves. So I'd say use this when you want an improved version of Oof 2. Next, we move on to JSON Web Tokens. These are JSON, basically, a JSON standard for transmitting claims. And they're actually used by OpenID Connect to transfer its claims. So the pros of using Jots are that they contain a payload. So this is good. You can put all sorts of metadata inside of the Jots which can be used by your software. Also, their integrity can be verified as they are signed by an issuer. And the signature can be verified using a public key. So the whole thing cannot be tampered with. It's very safe. It's API-friendly because they're easy to use and stateless. However, this is also partly a con because it means that they can't be easily invalidated because they contain all the state inside themselves so it's difficult to invalidate. So I'd say use these when you don't want to use... I see my slide has just not got the right tips on it. But it should say use these when you don't want to use OpenID Connect but you do want to use Jots. Okay, so next we have Neutral TLS. So it's the same technology as we're familiar with in our browsers which allows us to connect to websites securely and trust that they're genuine. So it's not just the client trusting the server in this situation, it's also the server trusting the client. So the pros are that it's very secure. As the name suggests, it's a bi-directional authentication process. Both parties gain trust of each other. The cons are that in terms of APIs, it's not really that user-friendly. It only really caters for machine to machine or due to the unwieldy certificate provision processes, you're not gonna have an end user doing that sort of thing really. But it is secure otherwise. So I'd say use it when you want high security and you and your consumers don't mind having to manage certificates. And the last one is multi-factor authentication. So this provides resilience through using multiple authentication methods. The factors could be things like something you know, like a password, something you possess, like an RSA key. These are obviously, these are used by banks and so on you might have a secure token that you need to log into your bank website or something that you are like your fingerprint. So you might have used your fingerprint that sensor on your phone to authenticate with an app. So that's an example of using something that you are. So the pros of that is highly secure. But the cons are that it's more complicated both to implement this and also as a consumer, it's a bit more complicated to do. But I guess that's the whole point. But if you also, if you lose your secure device then you wouldn't be able to log in or do what you wanted to do. Again, but I suppose that's the point of it. So it's not entirely a con, but yeah, I'd put it on the cons. So use this when you want high security and you and your consumers don't mind the inconvenience of doing that. Okay, so enough of these slides. I'm gonna now do some demonstrations. So what I'm about to demonstrate is three demonstrations. The first is using OWL2 with GitHub to generate an API token. And then the second one is using OpenID Connect with Octa to log admins into the type dashboard. And the third is using OpenID Connect with Octa to log developers into the type portal. So these demos are gonna use a standard type setup which includes a component called the Identity Broker. And what that is is a component which allows a type to authenticate against different platforms. It's an open source component and it comes with a number of different connectors out of the box which allow you to connect to different social platforms and so on. But don't confuse Identity Broker with Identity Provider. So it's sort of similar sounding but the broker is the type component and the provider is something like, it's gonna be something like Octa. So they are actually different things. Okay, so I'm gonna try and do this all one-handed while I still hold the mic to my mouth. Let's see how it goes. So the first demo is using OAuth 2 with GitHub. So we've actually documented this entire process on our GitHub Wiki for this project. So if you wanted to find out more about it, you can go to Google type Identity Broker and go to our GitHub page and you can check the Wiki out and read through how that works. So the first thing I had to do for this is not on here, so let's just go to GitHub, right? So what I had to do because we're going to use GitHub to authenticate a user, we need to create an OAuth application on here. So if you have a GitHub account, you can go to your developer settings, go to OAuth apps, create an application. You're basically given a name but the important thing is that you have a client ID and secret here and these are what we're gonna use to connect to GitHub and authorize access to this account. The other thing that's important on here is down here at the bottom we have an authorization callback URL. So this URL that I put in here is actually the URL of my type Identity Broker and it's going to allow GitHub to communicate with it to instruct it that hopefully that the authorization was successful. The path here includes a few important pieces. It has this one which is gonna refer to the profile in the Identity Broker that I want to use and it also includes this GitHub string which means that it's gonna be processing the response as a GitHub OAuth callback. So other than that, things I had to do I had to go into the type dashboard. If you've not seen this before, it's basically the piece of our application which allows you to manage your API configurations and so on. So I had to come into here, it might have locked me out, no it hasn't. So I had to create an API. So I created an API and it's going to target this HTTP bin.org website which is, if you've not seen it before, basically this, it acts a bit like an API itself so you can call different endpoints and get back some JSON data and so on. So what we've done is we've set up that so the API will proxy to there and we've also set up the API to use OAuth2 itself so both the type API is gonna use OAuth2 so is GitHub, so it's a bit confusing from that point of view, but there we go. So it's gonna generate a key and we'll be able to use it to access this API because if we try and access the API right now, there we are in Postman. Let's just make it a bit bigger. That's as big as it goes. So if I try and send this request now to my API it's just telling me that the authorization field is missing, right? So it's not gonna work. So we need to provide a key to get in which we will do in a second. Now, I can show you this. I'm not gonna spend a lot on this because it's a big load of JSON, but basically in the configuration for the type identity broker, this sort of section here is where all of the settings I've accumulated through going into GitHub, creating my OAuth app, going into the type dashboard, creating my API in there. I also created an OAuth client in there and all the details for all of those things I've configured and put into the type identity broker so that it's ready to go and use these resources. As I said, on our wiki, on the identity broker GitHub page, it explains all of this but I don't wanna go into all of that right now. Okay, so to show you that this works, what I'm gonna do, copy this, I have to get this URL, so bear with me one second. So what we have to do is use a bit of imagination because I haven't got an application setup that's going to start needing this login. So what I'm gonna do is I'm just gonna paste in the URL here, which is what the, if we had a web app that wanted to login using GitHub, this is the URL it would have to call. If you can see, you might recognize that it's the same URL which is in our GitHub application except it misses the call back off the end. So when I go to this URL, what's gonna happen is it's calling the identity broker API and saying, I want to use profile number one, which we saw the config for just now and I'm gonna use GitHub. So what will happen is the identity broker will redirect us over to GitHub and start the overflow with GitHub. Okay, so it's redirected over to GitHub. What we can see is it knows the name of the application that I set up in GitHub and it wants to access my account, but it only wants to access public data because we're just using this actually really for authentication, so we only want access to public data here. So as the user, I now get the choice, well, I can only have one choice, I suppose I could close the browser, but I'm gonna authorize it. So we click that and what happens is this will then authorize the application, it will go back to the identity broker and what we end up with, I appreciate this is a tiny text that's on the page, but basically it's redirected us back to what would be our web app. So you have to imagine this is where the imagination comes in, oh, sorry, we got another mic. I think the batteries went out. Oh, yep. So this is redirected us back now to our web app and in the URL it's included the key. So that's the API key there that we need. So the web app would consume that and then it could actually make the request to the API. So we can now go and check to see did that work. Hopefully it will. So let's put in our key in here and see what we get. Yeah, so there we go. So that was the full flow there. Obviously a bit of imagination required in that we don't have an actual real application, but we simulated it calling the identity broker which redirected to GitHub, which when we authorized it, it sent us back to the identity broker which then generated the key and redirected us back to our web app with the key in the URL. So there you go. That's the first demonstration. Okay, so next demo is doing a dashboard login with OpenID Connect and Octa. So the dashboard is the thing I was showing you in here which is the sort of the command and control center of type. So what this does is obviously it lets you configure APIs and so on and create API keys, but it's done so using users. Okay, so you create these admin users and we store a first name, last name, email address about that user, but if you didn't want to store that personal or professional data in the application, then you could use an identity provider like Octa and use OpenID Connect to actually authenticate the users outside of this application and not store this data in MongoDB, which is where it's normally kept. So in order to do this, what we should do is go and take a look at the Octa dashboard. So I signed up for a free account on the developer site and just started creating these apps on here. So the way that it works is you create applications. I created two. So the first one is this type dashboard. So if I take a look at that, I've got some settings in here. I just had to give it a name. It's a web application. Dashboard is a web application and it's gonna use the authorization code flow. And what's gonna happen is this time it's gonna call back again to the identity broker, but this time it's gonna use a different profile because in our configuration of the identity broker, we have another profile here. Profile ID two. And this profile uses a different action type. Although quite a few of the things are the same. One thing that's different here is the return URL is gonna go back to our dashboard. The previous profile didn't have that. This is a special endpoint that's on our dashboard, which is created for enabling these sorts of sessions to be created by where we're authenticating people outside of our application. And up here we have our client key, client ID and client secret. Those are the client ID and secret that are defined over, are they, or under sign on? No, they're not there. Well, yeah, so there they are. So basically those client ID and secret are copied into our profile config in our identity broker. And it will then be able to communicate with Okta to lock the user in. Okay, so I've also in here, I created a few users. So these users' details are now just in Okta. They're not gonna be stored in the type dashboard at all. I've set up four users and I've also set up some groups as well so you can do things like role-based access control. So I've set up a type dashboard group and a type portal group. And what that means now is that for my applications, I can set the assignment to a group. So I can say that only the type dashboard users can log into the type dashboard and so on. So you can split your users up into different roles there. Right, so to kick this one off, I need to get another URL. So while I like that, okay. Paste it in up here. So this URL is a lot like the last one. We're calling the identity broker endpoint to kick off the process. In this type, we're using profile number two, which is our open ID connect profile. It's gonna redirect us over to Okta and it's going to provide us with the login page for that. Yeah, so, oh, actually, one thing I need to do is to do this in a new private session because I don't want it getting my login cookie that I've already been using. Okay, so here we have the Okta login page. So for the dashboard, I set up a user. It was David plus Frank at type.io. Yeah, and password. So on this user, actually, and for the dashboard as well, I set up multi-factor authentication. So I'm gonna have to log in and also, oh, I missed the time, I need to name a password wrong, sorry. What is it? Yeah, let's try that again. Okay, so on this application, I've configured Okta to also require me to type in something from my mobile phone. I set it up earlier, but if I hadn't already configured it, I'd have to basically scan, if you're not familiar with the Google Authenticator. You, when you add something on here, you have to scan a QR code and it configures it on here. So I already did that. So it's ready to go and basically, I've got a whole bunch of numbers right here which are changing every 20 seconds or something and I have to get the right number at the right time, otherwise it wouldn't let me in. So for this user, it is three, four, five, nine, oh, four. Yeah, okay, took a little while. But so basically, what's happened there is the, once I successfully authenticated, just like with the GitHub situation really, Okta called back to the Identity Broker to tell it that I successfully logged in and not only that, but I also used my multi-factor authentication. And at that point, the dashboard just created an account for me. So this is done without the need to then store, I show you over here under users. I don't have a user for this Frank Bruno, he's not in here. So all that data is still in Okta and not only that, but I haven't had to implement any multi-factor auth for my type dashboard, it's all been handled through the Identity Provider themselves. So that's one of the real benefits of Identity Providers is that they do the hard work of figuring out how these authentication processes should work. And as new standards come out, they will also provide those as well. So it's really useful. And if I was to try, I'm actually not gonna close that just yet because what I wanna do is, I wanna show you what happens if I try to use a user who isn't in the correct group. So remember I created a group in Okta just for the type dashboard and this user is not in that group. So I can log in to Okta. It's gonna ask, yeah. So at this point, it doesn't realize, it hasn't bothered checking that I'm not in the right group, it hasn't got to that point yet. So my code is seven, four, three, six, three, nine. And at this point, it will verify and we will get an error message. So this shows you that Okta is doing the checks on, is this user in the correct group for the application that they're trying to connect into? So it's great for doing that. Okay, so the last slide. The last demo is the same thing again, really, but this time we're logging into the developer portal. So the developer portal is the component of type which allows users to, well developers to browse your APIs, see what APIs you have available and read documentation, sign up and register for API keys and so on. So this is the developer facing aspect to the type product as opposed to the dashboard which is the sort of management tool that the API owners use. So we can do the same thing with this. We can use Okta OpenID Connect. Now there's a slight difference because obviously it's a different product. It's not the dashboard, it's the portal. So it means we have another profile in here which is slightly different to the previous one but only very slightly. And pretty much the only difference this time is that the Okta application has changed. So we made a separate application in Okta so we have a different key and secret and we also have a different callback. This one is going to the portal, I don't know if you can read that, but it's basically the portal URL. It's a different URL to the callback for the dashboard but those are the only real changes here. So to start this one, let me just copy this URL and I need to go into my session. Same thing's happening. Identity broker redirects to Okta. Okta then expects me to log in. Okay. And I didn't have a multi-factor alternative on this one so this should just log me straight into the portal. There we go. So it logged me in now and I haven't had to sign up for an account on here already. The account was already created in Okta and none of my personal data is stored on the portal. So let's wait for this slide to change over. Maybe I have to close. Okay, so that's the end of the demo. So in summary, in today's digital world, privacy is becoming increasingly important as our personal data is being consumed and shared across a great number of services. Governments have recognized this and have reacted by placing regulations on how personal data must be treated. However, despite these regulations, data breaches are still occurring and personal information is making its way into the wrong hands, putting individuals at risk. As API owners, we can help protect our customers by using appropriate authentication techniques and utilizing regulation technology and identity provider services. I'd also say that avoiding capturing and storing personal data is a benefit if you can do that. Taking this approach is not always easy but you should be aware of your obligations and treat your customers' personal data with care. Okay, so that's the end of my talk. Before I go to the Q&A, I'm just gonna do a small advert for the TIC Singapore users meetup. So if you're interested in learning more about TIC, we run meetups every so often. Go and check out our meetup page at meetup.com slash TIC hyphen users hyphen Singapore and you can find out more details there. Other than that, I'll go to Q&A if anyone has any questions. Okay, well, I'm gonna be around and if you wanna come talk to me, feel free. Yeah, so thanks very much.