KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Unlock the power of industry-leading insights and expertise. Gain access to our extensive knowledge base, vibrant community, and tailored analyst sessions—all designed to keep you at the forefront of identity security.
Get instant access to our complete research library.
Access essential knowledge at your fingertips with KuppingerCole's extensive resources. From in-depth reports to concise one-pagers, leverage our complete security library to inform strategy and drive innovation.
Get instant access to our complete research library.
Gain access to comprehensive resources, personalized analyst consultations, and exclusive events – all designed to enhance your decision-making capabilities and industry connections.
Get instant access to our complete research library.
Gain a true partner to drive transformative initiatives. Access comprehensive resources, tailored expert guidance, and networking opportunities.
Get instant access to our complete research library.
Optimize your decision-making process with the most comprehensive and up-to-date market data available.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Configure your individual requirements to discover the ideal solution for your business.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
There are various ways that client applications may need to log in when going beyond passwords. With a username and password, client development is easy -- just collect a couple of inputs from the user and match them on the server. When going beyond these though, how can client applications be deployed and maintained in a way that the server still dictates what the client should present and obtain from the user when authenticating them?
There are various ways that client applications may need to log in when going beyond passwords. With a username and password, client development is easy -- just collect a couple of inputs from the user and match them on the server. When going beyond these though, how can client applications be deployed and maintained in a way that the server still dictates what the client should present and obtain from the user when authenticating them?
So my name is Travis Spencer. I'm the CEO of curity. And for those of you who don't know curity is a software vendor providing a very complete O oof and open ID connect server. And today what I'm gonna talk to you about is how we can use hypermedia to adapt client side logins, to go beyond password. So kind of adding into that theme that we've been talking about of passwordless, how can we actually use hypermedia to go beyond what we can do with passwords? So in this talk, I'm gonna talk to you about my answer, to the question that Phillip posed there of why are PO passwords still ubiquitous?
And I'm, I'm going to say that it's because of the simplicity of password verification and that that's stifling progress. And I'm gonna talk about how we can use hypermedia to actually make the client still simple and guide the client through complex login processes and how we can combine that with oof and open ID connect so that the integration actually stays simple and standards based. And that may give you a demo of that. And briefly at the end, talk about attestation and how we can do this in a secure and safe way by knowing if the application is first party or third party.
So briefly passwords are easy to implement, right? I mean, in order to actually do a password, you need to check something that is known at the server. The client has to collect just two inputs. Like we saw a couple presentations ago, very simple gathering of those inputs and actually pretty simple for the end user too, because they understand how this works after decades of training, even new users know how they work. It's a simple post to the server, the server verifies it.
And we, we have an understanding of who that user is. At least to a degree. What we want to do is we wanna keep the it's simple for the client. Even if the server becomes a bit more complicated, we can manage that complexity, cuz there's fewer of them than there are of clients. So hypermedia for those of you don't know is an architecture for designing applications. It's an architecture that's used by the web. So it's highly scalable. It can be used in a broad range of applications.
And what's interesting is that for every website that consumes or that traverses the web, you don't have to reprogram the web browser. So the browser itself is able to adapt to the, to the programming code that it receives from the web application and, and present to the user, what it's supposed to do. And so hypermedia allows the client application to remain simple and to interact with the server based on its guidelines and what it is being instructed by the server.
So we can actually even use this for a login process where the server can guide the client through a complex procedure, a state machine where they're originally unauthenticated. And at the end of that state machine they'll be authenticated. So hypermedia is a great architectural pattern for solving this. And we can wrap this up into an API to perform login that will allow us to do simple password based login, but also any other form that the server might instruct the user.
As long as that browser can understand the hypermedia representations of the resources, it will be able to traverse the user through that login state machine in order to keep that integration with the client application. Simple. What we want do is we wanna start with OAuth and open ID connect. And by doing this, the client process for initiating that login or entering into that state machine will follow a standard, make it that integration easier. But then at that point, allow the client to start negotiating different representations of the states within that login state machine.
So instead of getting HTML as it traditionally would, it can get a different representation perhaps based on Jason, that it can parse and use to show the, the different screens collect different kinds of credentials and traverse the user through that authentication state machine also by using oof and open ID connect, the end application will be able to get an access token that will, it will be able to use to call APIs the entire process of this login.
Once it gets to that final state and the state machine, whether successful or error can also be communicated back to the application using open ID connect and OWA. So to show you what I'm talking about, I thought it'd be easier with a demo. So I'm gonna switch gears now to a demo application where I, I am consuming the hypermedia authentication API. So here it is, this is my little simple application.
And as you see here, it's actually starting by making a authorization request, according to what you would find in open ID connect, where I have a client ID, I have a redirect you or I, and I have some different scopes that I want to have. And one, I did that when I do that next, the client, what it's going to get back is a representation of a state in the state machine. And that state is including lots of different metadata actions that can be taken on it. It has a kind, this is an authenticator authenticator selector.
So this client is rendering in this fashion, but a different hypermedia client that understands this media type might represent it differently. It has within it, a select authenticator template, which is email. The one you see here, we have another one, which is if I scroll down a little bit, we about then like Phillip was talking about, we also have bank ID, which I'll show you to have different authentication methods.
Some of them simple like this username and password one, some of them more complex, but the way that the client got this was by saying that it can understand this kind of resource. So it doesn't just understand HTML. It also understands this hypermedia representation of the authentication selector page. So then it got these different options. See here also how my application and URL isn't changing. So this is a single page application the entire time that I'm traversing this state machine.
So if I select the username password, first of all, just to keep it simple, I do a post back to the server and the server drives the state machine to the next state, which in this case is gonna be a place where I can collect a login form. And on that, I'm gonna have two inputs, a username, and a password, which it renders in a traditional sort of way. And then in this client, I, I chose to use HTML elements that my password manager even fills in for me with my credentials. So I log in and then the entire state machine is complete.
I'm finishing up here with a links that take me to the callback URL. I'm told that the type here is an OAuth authorization response. So the client gets at this point, an OAuth authorization code and can complete the open ID connect request that it started. And if I were to do that, then I would convert that to an access token and a refresh token. Okay. So that's password, but let's see now how this goes beyond that. So we'll start a new flow.
And so here, before what I was actually skipping over even was this redirect state because I, I clicked the checkbox real quick to say that whenever a client gets a redirect step, it should automatically follow it kind of like a browser does when it receives a location response letter that automatically follows it. So this kind of behavior of the redirect is, is used in this implementation. This is another kind of resource. And now in this run, I've changed my client to just kind of show you that.
So you can see that there are different representations of different states within the state machine. So now if I go here to the authenticator selector page, I get the same representation before, but now I wanna select a different authentication method. So now I select something called bank ID, which is a way of logging in that's pervasive in Sweden. I'm told that this kind is a bank ID, same device. It has a template here and it has actions on it, which is a login. And in order to do that, I need to have some username, same device, which is a hidden element.
So the client might choose not even to show me that, but in this case, I want you to see that so that you can experience more of the demo. But here, if I click that on that login, I'm again, redirect it. I follow that. And I get another representation, which is the next step in this state machine, where I even have an auto start token that will launch open an application that supports this custom scheme and will log the user in with something more complex than username and password, which is in fact, an application installed on my laptop here.
So if I just log in, in this fashion, I'm logged in now. And now this client is told in here that the response type to this includes information about the, the client that it should pull to see if it should continue in this state machine to the next step. So if I submit that poll, I see here, yes, the user status is done. They're authenticated, they're logged in with bank ID. And the next thing that you should do is go to this, this other link.
So if we follow that link by clicking this button, that my client has rendered, I'm taken back to the OAuth server where the authorization flow is complete. And I have an access code logging in with a, something more complex than username password. And my client application hasn't been changed at all. So that hypermedia client allows me to understand different credentials without having to be reprogrammed by just understanding the different representations of those resources. It can log in in lots of different ways.
So in order to make this secure and safe, one thing that we need to know is we need to know who the client is that we're talking to. And this is something called attestation. We need some sort of proof of the actual client's identity. And these days with mobile phones, they have essentially smart cards built into them.
And the, the private keys on those smart cards are assigned by trust routes that chain up to apple and to Google. So we can actually, from those trust routes, determine if the, the mobile device is rooted. If it's gone through a secure boot process. And then we can also determine if it has a certain application ID that has been registered with a developer when it was published in the app store.
So by knowing that identity of that application and the environment that it's executing in, we can even know that this is a first party or a third party application, meaning it's provided by the same organization that runs the authorization server, the open ID connect server or a different party. And based on that, we can decide to use different credentials. Like if this was a third party, it would behoove us to use some credential. That's not on the same device so that we can avoid different attacks that would be possible otherwise.
So the server conditionally can mandate those different credential types to be used, but the client can adapt to 'em because, because it's a hypermedia client. So no matter what the server dictates will be able to handle those different kinds of media types or different states within that state machine, according to the media type.
So in summary passwords are easy for clients to collect easy for the server to verify and pretty easy for the user to enter in and work with because of many decades of, of training, but hypermedia allows us to provide other login methods that will keep the client simple. The server becomes more difficult, but the client itself remains simple and the user can log in with different methods that have better user experience. Like we talked about in previous sessions and ones that aren't even invented yet, perhaps.
And we can combine these with open ID connect and O also that the integration remains standards based and standard compliant. And we can increase the security of by knowing who the client application is in an, at stated, at tested and trustworthy manner, using trust routes that we trust. So with that, I thank you so much for listening to our talk and coming to EIC. I was very glad to be here with you in person. And if you have more questions, be sure and find me afterward. We also have a, a booth over here in the, the area here by the stairs. I'd love to talk with you more. Thank you. Okay.
