If you want to get in contact about speaking engagements, please email me at [email protected]. I usually speak about or run workshops on IdentityServer and OpenID Connect, however when Dom & Brock are hogging this topic I enjoy talking about ASP.NET Core, Azure, Docker, and OpenID Connect on other platforms. Travel & expenses are a minimum requirement to offset my employer's loss of a resource.
“It’s okay; we’ll build it ourselves.” When discussing identity, it sounds insane, but is it? At first glance, sure; however, after four years of implementing OAuth and OpenID Connect providers for customers big and small, I can confidently say that it’s not as crazy as it seems.
Over the past few years, there has been a growing number of software developers entering the identity space, both integrating client applications and even eschewing the major identity platforms and implementing the specifications for themselves. Surely some of them must be doing something right.
In this talk, I'm going to discuss why some companies are doing it themselves, the benefits they are receiving as a result, and clear up some common misconceptions of “doing it yourself”. We’ll even see just how easy it is for developers to create an OAuth and OpenID Connect conforming platform.
We all know passwords are bad, just look at the number of security breaches and the need for services such as haveibeenpwned and pwnedpasswords. So what’s the alternative? There are dramatic articles telling us that common 2FA techniques are phishable. Should we therefore disregard them? Is there even an unphishable way to authenticate? Should we all just up sticks and move to the Blockchain? In this talk I’m going to move past the rhetoric and sensationalism surrounding passwords and authentication, taking a pragmatic look at the past, the present, and the future of user authentication. Topics will include: evolution of passwords, storing passwords & what that really means, MFA, Phishing & MFA phishing, secrets and ciphers, spooky biometrics, and FIDO2.
OAuth is well established as the go-to protocol for API Security, but there are still a few application types which struggle to securely fit into the OAuth story. This includes devices where input is tricky, such as inputting a 20-character password using your TV remote on an A to Z keyboard. Or devices where there is no browser, where the dreaded Resource Owner Password Credential grant type still reigns king. Finally, there is a solution, with the all-new Device flow for OAuth, specially designed for these pesky browserless platforms or devices with limited input methods. In this talk, we'll see the device flow in action and look at how it is an improvement on existing solutions using real-world scenarios where it should be used.
Distributed ledgers and self-sovereign identity are a match made in heaven, and there are many products out there already that implement this concept readily available to developers and consumers alike.
After integrating with some of these providers, both manually and using client libraries, it’s clear that there’s a high variance in implementation quality, but at the same time some commonality in design decisions.
In this talk, we’re going to take a look at some of the common functionality of these providers, what they’re getting wrong from an integrator's perspective, and what we can learn from them moving forward.
OAuth is well established as the go to protocol for API security, but there are still a few application types out there that struggle to securely fit into the OAuth story. This includes devices where user input is tricky, where data entry uses a tv remote control, and everyone gets to see you slowly type in your password. Or devices where there is no browser, where the dreaded Resource Owner Password Credentials grant type still reigns.
Finally, there is a solution, with the all new Device flow for OAuth, specially designed for browserless platforms or devices with limited input methods. In this talk we’ll see the device flow in action by extending IdentityServer 4, an open source OpenID Connect and OAuth written in .NET, and look at how it is an improvement on existing solutions using real world scenarios where it should be used.
As software developers, we work in one of the most rapidly changing industries available, and in recent years this has been doubly true when we talk about security. Nowadays we have to accommodate a variety of client applications, hosted on any device and anywhere in the world and this means we must take a closer look at how we handle authentication and authorization when dealing with our protected resources.
In this tutorial, we'll be looking at the basics of claims-based identity and access control, OAuth and OpenID Connect, and how IdentityServer can simplify all of this for you. We’ll finish the tutorial with a working installation of IdentityServer, running on .NET Core and Linux, protecting APIs and authenticating users. Whilst we'll primarily use ASP.NET Core throughout this tutorial, the final IdentityServer implementation can work with any application on any stack.
AdminUI is the first supporting product for the IdentityServer project, brought to you by Rock Solid Knowledge and the IdentityServer team. AdminUI brings out of the box features such as user & claim management and simplified IdentityServer configuration management, removing specification specifics when handling OAuth and OpenID Connect configurations. In this talk we'll walkthrough the major features of the AdminUI product and how it can help both new and existing IdentityServer projects.
At the end of the talk we will also have a sneak peek at the feature set for our next product: IdentityExpress. This is a turnkey solution of IdentityServer, bringing .NET’s favourite OpenID Connect Provider to the main stream, without the need for intricate knowledge of the framework or authentication protocols.
Some of the most understated improvements in ASP.NET Core are those found ASP.NET Core MVC. With ASP.NET Core we have new tools available for web development: we now have access to web development standards such as bower, npm and gulp, we have simplified resource caching, versioning and failover, and new approaches to partial views previously unavailable to us. In this session we will take an existing ASP.NET MVC application and migrate it to ASP.NET Core from ‘new project’ in Visual Studio to feature parity.