Good afternoon, ladies and gentlemen, welcome to our equipping, a cold webinar, universal SSO strategies and standards for single sign on across web and native applications. This webinar is supported by P identity speakers. Today are me Martin Ko around the principle Analyst, a call and Pamela Dingle who's principal technical architect at ping identity. The topic we will talk about is how to deal with this sort of move from traditional web applications to an increasing number of native applications, particular and mobile front end, and how to anyway support single channel, so to speak universal things. And on before we dive into the topic, some general information, some housekeeping information, keeping a call as an Analyst company will provide enterprise it research advisory services, decisions, support networking for it, professionals through our research services, our advisory services and our events and that context. I might note you that today we have our so-called as red nose day, which allows you to get to gain access to our research for free for today.
So there's, I think it's a great opportunity to test drive our research and some of our other offerings, we have a number of upcoming events. The most important one clearly is our European identity and cloud conference, which will be held next year, may tenths to 13. So Munich again, it's number 10. So it's a Trioli for us. We also will do next Tuesday, next generation cybersecurity dialogue, which will be in trauma language, which will look at a number of cybersecurity topics and where to move. So we will look at this topic done in this smaller event held next week regarding the webinar, some guidelines you are muted centrally, so you don't have to mute or unmute yourself. We are controlling these features. We will record the webinar and the recording will be available tomorrow. And the Q and a session will be at the end.
So you can answer questions anytime using the questions feature in the good webinar control panel, which I always appreciate, because then we might take would one a question during the webinar. Otherwise we will, as I've said, do a Q and a session. The agenda for today is split into three parts as usual. The first part, I will talk about different approaches to achieve single cell across web native apps, available standards, not that much and deployment models. And the second part Ingle give insight into best practices for how to the benefits of universal SSO can delight your and users and make your business faster and more efficient. So she will dive more into the standards area, et cetera, while I will more sort of pull the crown for this topic. So I want to start with some overview, which you might have seen some of my other presentations already.
So every one and everything become connected. And what we are currently facing is something which is challenging, not only for the information security departments of organizations, but for the entire organization. So we see fundamental change changes in the way we have to deal with identities, with access with connected things. And this is sort of the, the big picture. So people are part of organizations. They act on behalf of organizations, but they, and they, they start using an ever increasing number in variety of devices. So amongst the traditional PC or notebook, there's mobile phone, the tablet smartwatch, there might be other things in future yesterday, yesterday, I've seen a, a demo where then windows, we appeared in the, at the screen of a Tesla car. So more and more devices and more and more things. So when things on devices start communicating people, U use things, things provide data to our organizations have far bigger variety of, of communication and connectivity than we ever had before.
And so what we do has to, to support this changing environment. So the days where we had a situation where user only came in through his web based login, so through website, and he was indicated with username and password. These days, our past people tend to use apps. We see at, if we look at windows 10, we can, we'll see the same apps, windows 10, whatever notebooks and tablets and phones. So this world is changing the way we communicate, the way we access information, information systems is changing. And that means we also have to think about how can we make it convenient. Most of you will have looked at this for a long time, ongoing discussion about usernames and passwords and the big quotas password stats statements we regularly hear. I think the point behind that is how can you make it easy? How can you support the user requirements, but how can you keep it also secure and clearly having different username, password combinations for every app and every website you access is not the solution.
So we need single and on, we need to enable single and on flexible way with various authentication mechanisms and we have to do it for all the various types of access. So not only the traditional, a human being authenticates actively just username and password when he accesses a website, but also for the new ways to access information systems. That is, that is sort of the big context of today's webinar. So when we look at the who, what, where, how type of access. So traditionally we had sort of this, the user uses notebook or SPC to access fat client applications, which was still a part of the challenge. Yes. So frequently that was sort of a proprietary way of authenticating. Sometimes it's curb integrator or whatever else, but this was a sort of the very traditional use case. Then we had the web applications, appearing, web access management came into play. So sort of gateway solutions sitting in front of the web applications, doing the authentication and the very core screen, in most cases to these web applications.
And then sort of the next level was also looking more at the outside world. So how can you work with business partner applications and particular business partner, web applications Federation came into play here, particularly for this use case when it's about saying, okay, I have a lot of users in my organization which want to access the, or need to access the business partner web web application. Then clearly it makes more sense to federate these users instead of creating new identities at the business partner side, manage these and keep them synchronized and all the other stuff. So Federation came into play here, and this also works for external, so users, which are using their notebooks for, to access business partner, web applications, or internal web applications, also consumers. So the, the use case of consumers accessing and then whatever Porwal or so running a web application running on premise protected by a web access management solution.
This is a very traditional use case right now. So we have also this use case of people coming in, in the traditional way, even, even in a way, which then supports some bigger challenges accessing fat client applications. So either by, by putting a web interface in front, what just been done regularly, or in some cases also more by moving towards sort of virtualization approach. So making a, a virtual virtualized view available to yeah. It's user. So this is sort of an evolution we have have seen over the past also with cloud services coming into play and for cloud services. There's not that much difference. So when we look at how authentication do cloud services stand to date and Federation standards are one of the, the standard ways of doing it. However, we also see a lot of cloud services where we more or less have a standard web based authentication with tools, also supporting forwarding user name, password information to these sites for all these situations where Federation standards aren't supported yet.
So this is basically the situation we have been facing. And right now there's another element in this equation and this element is the mobile device. And it's the situation where we don't want to use this mobile device the same way we use a notebook, for instance. So we don't want to use a page because it's not very convenient to enter credentials for using the browser, particularly the smaller types of mobile devices to enter, use user name and password. It's not really convenient. And there's a growing number of native apps. So apps constructed to run on a mobile operating system and these apps work differently. And this also sort of influence as the way we need to do our indication, our single cell on. So let's remove all these errors and look at what happens here. So clearly one way to work is the web access way.
We can do it again. That way we can say, okay, we use sort of a standard web authentication, etcetera, but as I've said, it's not convenient. So what really happens is that's what we really see as the, the, the fundamental change in these days, we see APIs and access through APIs emerging. So these apps use APIs to communicate with the backend services, and these APIs can be exposed by over virtually all applications. So this even in includes the client applications, and then the access goes through these APIs and it commonly uses them standards for that type of API based access. So, and panel will talk about is more in detail, but clearly we are talking very much about OWA to and open ID connector at that level for that type of access. So the app sort of acts on behalf of the user and the app requests access to APIs of one or more systems.
And so we have to sort of find the way, and this is where, again, the singles and on question on this entire story, entire challenge coming comes into play. We have to find ways where this allows us a seamless, single sign onto variety of services. And as I said, Pamela Dingle will go more into the tech technical details and the backgrounds, but access through API is clearly is one of the big challenges. But on the other hand, if you look at it from an sort of, of enterprise infrastructure perspective, either on premise or in the cloud, we also have to find ways to do it in a consistent way, not having too many spread infrastructures running, but moving towards, and I would say RA or well integrated, consistent infrastructure. So what about SSO? When we look at us, oh, it's about the user being able to access a variety of systems, and there are various ways we, we, we, we might experience SSO.
So there's the Federation approach. So when we federate to a business partner, based on our internal on-premise active directory, also education, then basically federated SSO is one of the most important benefits of that type of access web access management. Traditionally also has the impact of saying I can access to a number of web applications because all of these are behind this web access management gateway style of sync. And if we look at APIs and API gateways, it's basically the same. It's the idea of saying, how can I consolidate access? How can I manage access? How can I manage APIs as well? There's a lot of stuff around that, but also how can I enable single on in that case? So, and what is important to understand all of these Canon rely on identity providers and all or directories, which is part of the thing happening behind, or we seen on identity provider and that's, they all can enable and, and, and allow us to signal sign on to backend application.
So this is basically when we look at universal. So these various ways, they are not that far away from each other particular Federation and, and API based accesses from my perspective, in many respects, very close to each other. So when we look at how to deal with the changing world, with mobile applications, with native apps, then clearly looking at how can we find a way to sort of consolidate this, to move towards a universal things. And on this is one of the most important things and, and technology. When we look at Federation web access management, API gateway with this sort of technology is conversing and sort of has been for by if you look at the offerings of a number of when sort of been convert from the very beginning. So it makes a lot of sense to, to look at how can I with a more or less unified approach provide a universal single on. And with that, I will hand over to Pamela for her part of the presentation. And as I've said, she will dive right now, far more deeper in detail, also looking at standards and other stuff.
Thank you so much for the introduction and for setting things up to, to talk about sort of standards, universal SSO. It's a wonderful topic I have to say in that. I think there's a lot of argument and debate that, that we could have over what it means and why it's important. I will try and give you my perspective on this, and hopefully it will have a bit of value for those of you who are trying to build architectures, you know, and understand what technology those architectures should consist of, because it is a changing landscape. I mean, as Martin said, everything is sort of has turned and pivoted 90 degrees from what we're used to. So let's dig in here. So ultimately when you think about what we do as identity professionals, there are two first order problems that we must solve. And, you know, Martin has talked about this a little bit, but it's important to understand the time context of these two things.
So first of all, is, is to secure the authentication ceremony. So this isn't any more, just a case of validating a password that day has long gone. And when we talk about single sign on, really what we mean are, are two things. There's a convenience factor of single sign on, which is allowing a person to prove themself once and then rely on that proof to travel everywhere. But the second part of it is that you can abstract your authentication ceremony from your applications, which means that you can create a complex, meaningful, and highly secure interaction for the, the actual process of proving who the person is. So securing the authentication ceremony is a huge part of any identity infrastructure today. And the second piece that has been really less emphasized in our industry is securing the resources at the time of access. And this becomes a very big deal.
When we start looking at native and mobile applications, these two things were, were tightly coupled from a time perspective in that a user was in the browser. So the user was present. They would work for some amount of time, but you could be pretty sure that that's, you know, eventually they would go to lunch or go for a cigarette break or shut down their computer. And that session would end. So there was, you know, a very specific tie between when the ceremony took place and when the resources were accessed. And there are mechanisms that we've all developed such as an idle timeout or a session timeout that help us ensure that the authentication ceremony never becomes stale. However, now that we're moving into a mobile world, that isn't always the case. If you think about what you do on your phone, you generally log in and then you use the app you've authenticated to for a long, long time, weeks, months, if it's a social network or a video game, it could, you may never again be prompted for your identity unless you break your phone like I did yesterday.
And unless, you know, if you have to reinstall an entire phone, then at that time, you would have to go through your authentication ceremony again. So these two things are, are huge, important pieces of work. And yet the even larger job is securing. What goes underneath that in order for you to make the right resource time decisions, you have to have the right data behind. And so there's, there's, you know, you are, are building a, a very big, very fancy authoritative picture. And then you are trying to leverage that picture in the moment to make correct accurate, secure decisions. None of this changes, none of this changes. This is really the same problem we've had for a long time, but now our tools are better. Our methods are more varied and the stakes are higher because of the type of breaches and attacks that are happening right now.
So if you, if you look at what we have today, you know, Martin talked about the web access management piece and, you know, for a long time, especially on the resource side of the house web access management was the, the gold standard. And generally speaking, that was accomplished through an encrypted session cookie, right? So you would authenticate once you would get this encrypted session token, and that would be your anchor primary anchor, to be able to travel through your different resources over time. That setup has done a lot of a, a lot for our industry, because it has really introduced that concept of a common authentication ceremony. And it has also, you know, the introduction of Sam in the last 10 years has given us this concept of a, a secure introduction in that I can authenticate in one place. And then all of a sudden the responsibility for determining who the user is changes.
It is no longer the responsibility of the user to prove themselves everywhere. It is instead the responsibility of the organization to introduce the user to all of their separate application contexts. And this has worked very well for web, you know, we've done very well. That's why we've had so much adoption of Federation and of web single sign on in general, but here's what, here's the challenge in front of us today. The challenge is that this passive concept, this idea that a person is pushing the buttons in a browser window, that concept is now outdated. And in a mobile context, there are, there are now two scenarios in a mobile context. There are the moments when the user is present and manipulating the application. And there are moments when the application is acting on behalf of the user with or without supervision. And those moments from a security perspective have to be treated differently and they change how our architectures work.
So active software can do things that we don't ever imagine, right? They active software can travel to APIs. We didn't know existed. It can ask for data that we never knew. We had access to. You know, it can do a lot of very bad things, or it can also do very good things, like keep you updated and send you notifications on your phone when something is about to happen, because data has changed and the software has silently access those APIs. So there is a security risk that we have not addressed with SAML, which is our gold standard in the industry for, for secure introductions of users. And that risk is about the fact that if you introduce someone, you are pre, you are assuming that they are present and that does not work. If that piece of software can run off and, and work on our behalf to imitate us and impersonate us.
So that it is really that question of, is it the user present in the browser, or is it a piece of software impersonating us? If it is a piece of software we never want impersonation to happen. We only ever want delegation to happen. That is the basis for the introduction of oof, 2.0 and open ID connect as you'll see in a minute, oh, I will address the scale question. The other difference is if you think of, of how many web web applications you might access, and then you think of how many telephone applications you have on your smartphone, there's a potential difference there in an, you know, maybe an order of magnitude, maybe not quite so much as that. However, from an enterprise perspective, when you had to deal with a hundred or even a thousand applications that you wanted to send your users to, that's one scale of problem. When you have 20,000 employees and each of those 20,000 employees are running five mobile applications, and each of those five mobile applications are accessing 100 APIs. Then your scale is off the charts. And that is another reason why we've had to change the, the paradigm for a single signup.
So ultimately we have evolved towards something called OAuth two. The important thing to know about OAuth two compared to SAML is the asymmetrical nature of the OAuth two standard. When you think of a, of a mobile application, a mobile application is a smaller, less sophisticated piece of software than say a large web application like a Salesforce, or, you know, something like this, this small piece of, of code is reliant on APIs that are external to it. And it is consuming from those APIs. And that asymmetrical relationship is, is doubled down by the idea that we don't know how secure that little piece of code is running on that device. So SAML is, Sam is not an asymmetrical concept. Sam expects that you have good crypto and good security on one side and good crypto, good security on the other side. And that those two things will equally work to validate a fairly complex structured XML document.
We can't do that with mobile because we can't necessarily trust that we can place a certificate on that box. Plus we don't necessarily want developers to have to deal with a soap stack and to deal with all of the validation requirements necessary for SAML. These, all of these pressures are what are pushing us towards a different set of standards. So what are the principles? If, if you are architecting an identity world, you're really looking at six principles, you need it to work for web mobile and API. And that is a fairly new responsibility. You need it to work for all of your identities. And by that, I mean, if, if you're approaching this from a security perspective, you, you, can't only secure your workforce. If you have partners that are accessing your information and you are managing identities on behalf of those partners, then they become a risk obviously to your organization as well.
So your identity architecture cannot pick and choose anymore. It has to be comprehensive. We believe that federated architecture is a requirement now for any kind of universal architecture, because we are no longer pushing things into a single domain. We are spreading our applications across many domains, hundreds, maybe thousands of domains. And each of those domains has to be individually secured. So we have to know that as data travels across those domains, that they can operate, they can be secured independently, and that the data as it travels is happening in a, you know, in a way that can be audited in a way that can be governed. And hopefully in a way that is secure, we think the best way to do that is using standards. And the reason that we believe standards are critical is because the more consistent you can make your architecture, the more predictable you can make it, the more that you can start to see trends and leverage intelligence to note traffic patterns that don't just occur within one application, but occur across all of your domains as ripple effects.
And an example of this, if, if you aren't using something like single sign on, you have a, a, a serious risk of credential farming today where somebody, some user of yours has reused a credential and attackers are, are attempting to see if that credential might be valid for your organization. And so what happens is they, they just try it. They travel to every single application and they give it a try. And if it works they're in, and if it fails, then they move to the next application. So being able to see those kinds of attempts across multiple applications, even when those applications are in different domains, gives you an edge and allows you to start to see larger system patterns.
Obviously internet scale matters as we all start to accumulate wearables, and as devices make their way, you know, internet connected, organizational devices begin to flourish. We, we simply can't manage every single trust connection that we, that we need to establish in an organization. It has to become automated. And that, again, pushes back to our principle of built on standards. If it's built on standards, it means that you do not have to write bespoke software to connect. And every time you write bespoke software, you have the risk of error, user error of the developer, not understanding the context. And it's not to say that error doesn't exist for packaged products, but the hope is that those errors are at least found more quickly identified because the application is being used over and over in multiple contexts. And then lastly, flexible deployment. Obviously we don't really care. I mean, at ping, we don't care anymore about whether your data is in the cloud or on premises. We have a simple rule, which is if it speaks native standards, then we, then the job is done. You can check it off. If it doesn't, then we need to bridge your identities. And we can do that too. So it's really a question of, of does every given resource domain that you're trying to protect. Can it be enabled or is it already enabled? You know, that's, that's really what we, what we're looking at now.
All right. So from a security perspective, this is what I think universal single sign on needs to look like. We believe it ping that primary credentials carry the highest risk of impersonation. If you can steal a primary credential. And that credential is the only credential that you have to know, whether the user really is who they say they are, then you have a lot of risk associated with your organization. So the strategy of mitigating that risk is to multiply the number of primary credentials you use. So that, that is essentially multi-factor authentication on the top left of, of this picture. We, we believe that multifactor authentication is just the beginning. So there are multiple passive factors that systems can detect about people, such as what location they're in, such as what device they're on. All of those other factors will in fact, fall into this primary credential box and hopefully create an authentication ceremony that is extremely secure.
But once that authentication ceremony is done, then the goal is to use a different economy for the rest of your applications. And that is an economy of bounded credentials. So no longer do the primary credentials come into use after you've proven them. You now start sending assertions and tokens and, you know, small delegated pieces of authority around to all of your resources. And this creates a buffer between your resources and your user, such that the user can have a trusted engagement with your, your identity platform, your identity provider, and then they leverage all the benefits to your resources, without your resources ever having to understand what those primary credentials were. Now. I, I realize that for those of you, who've been in the industry for a while, this, this works beautifully with SAML. This is not a new architecture. However, there are whoops too far.
There we go. There are other standards that you now need to consider for all of the reasons that both Martin and I, and I have talked about so far, we have open ID connect. We have oof, 2.0, we have skim and we have Fido. And all of these separate standards bodies are contributing to, to improve the segmentation of credentials in an organization. Let me start with oof two, because we were talking about native mobile, and that's a critical piece for this particular group. Oof. Two is a delegated authorization platform. So what that means is that OAuth does not authenticate the users. The users still authenticate using their trusted authentication ceremony. And that can happen via SAML. If you have, you know, if you have a, an OAuth, an OAuth infrastructure in one domain and you have user repository in another domain, then that oof server can simply make a SAML authentication request to the second domain, to get an assertion about who the user is and that assertion can come back and be vetted.
And then that oof server will issue an access token. And that access token is good for APIs. It's meant to be played from a native mobile app or other client to an API. And the API does not get any identity information from that token, that token, at least by default, you can actually make the tokens in intro respectable. If you want to, the specification does not actually dictate what a token looks like. But the goal is that that access token is simply sent on every API Fe that and the, the resource, the API is able to then discover from the token who the user was and what the user was authorized for. So the, the bounded credential here that access token is not a secure introduction. The way that a SAML assertion is it is a valet key, right? Or a coupon. Please allow this client to get this information on behalf of this user from a security perspective, that is a big deal.
And if you were to ask me what universal SSO has to be, that is the number one thing that is important is I, a lot of people have this idea that single sign on is simply opening the doors, right? Just allowing everyone to get access to everything all the time. That is exactly wrong. What universal single sign on is, is knowing every single transaction that takes place in its context, and being able to secure every single one of those, those transactions. That is what OAuth can give us, because our clients must ask for delegated access for specific purposes. So if you can imagine that you're building your identity architecture, what you're really building is exactly that set of building blocks. How granularly do you want to request? You know, how do you wanna design the authorization that your clients can request and execute? And how can your security infrastructure leverage that knowledge to understand whether people are misusing your resources?
All right. So this, the specifications that I'm talking about here, they do multiple things. OAuth I've spent a lot of time on OAuth is about enabling clients to easily access data from APIs without having to have your developers worry about identity. Open ID connect sits on top of oof, 2.0 and is a critical standard for us in the identity world, because open ID connect puts identity on top of oof. And by that, what I mean is when a client requests an access token, instead of simply getting a thing back that they then replay to their APIs. What open ID connect will give you is, is essentially a marriage of SAML and OWA. It will give you an ID token, which is an assertion that tells you the context of the user interaction. It tells you, you know, which identity provider that the users is interacting with.
It tells you who the user thinks that they're, that you know, which client, the user thinks that they're interacting with. It tells you claims about the user. It tells you an identifier about the user. So if, if you are writing a mobile app and you just blindly accept tokens and then play them onto APIs, there is an element of risk there. Adding open ID connect on top allows you as the person writing the mobile app to both validate the identity, validate the authentication context, and then simply replay your access token off to APIs. The way that you normally would, no matter what. So those two things address the issue that I brought up at the very beginning of user, not presence, scenarios. So in this case, if you use oof, 2.0 and open ID connect, when you make your authorization request, you, the user is present.
They have to consent. They have to authenticate the data comes back and ID token represents that that user present interaction. And then you move into user, not present mode, which is you have a small delegated amount of access represented by a token. You're going to use that token at an API. And there is no expectation that, that, that that user will be present for any one of those API fetches. So I hope that works as an explanation skim. There's very good news about skim for those of you who are not familiar skim 2.0 has just been ratified as an RFC in the I ETF. So this is very exciting news. It's, it's real, it's standardized. It took a long time to get it there. I will tell you that I thought it would be done almost two years ago, but we have it. Now. It is reliable.
It's tested and people are starting to implement it. The important thing about skim is that skim is an API and exactly the kind of API that you would access from a native mobile app. It allows you to create users, delete users, working bulk, and it allows you to synchronize your resources across all of your domains. The last two Fido and account chooser. I, I won't talk to you too much, cuz I feel like I need to move on. But account chooser is interesting because account chooser allows you to begin to change the user experience and to change the trusted user ceremony.
And this goes back again. So another precept of universal SSO is that everybody has information about the context of the user. Every resource domain knows something. And what we're seeing right now as a trend in the industry is that that information may not be authoritative, right? It might be something that a resource domain has observed, but it could be a lie. It could be a misdirection. However, when all of the resource domains collaborate and they all start sharing information about what's happening, even the very small things, then sometimes you can construct an entire context out of a lot of very low assurance hints. This is a huge sea change for us in the industry. We've always only depended on things that we know to be true. What account chooser does it is it allows, for example, an application to say to their, to the identity provider, hello, identity provider.
I don't know for sure that the person who's trying to authenticate is Pamela Dingle, but I think it's highly likely. So it's a suggestion. It's a hint and that hint could be absolutely wrong. It could be that my mother has just logged into my machine, you know, to do something. But 90% of the time, it's probably right. It's probably me. Who's using my machine. So this idea of starting to, to accept hints from multiple resource domains and to use it, to tailor the user interface and to use it, to tailor the security, the overall security posture of your organization. That's gonna be the fun I think in our industry in the next little while. So I just wanted to very quickly talk about actual architectures. We have a very simple architecture here, which I think many of you will be familiar with where you have an active directory inside of a network perimeter accessed from a Federation server via the LDAP protocol, and then bridged out to internet resources using the SAML standard.
This, you know, this is really our canonical architecture and it works wonderfully, but it is not the architecture that most complex organizations are, are looking at it doesn't encompass enough of their problems. Instead, what we find at ping is that many of our customers are trying to get identities in. They're trying to get identities out. They are dealing with some cloud services, but they're also trying to protect their own applications. Now, if you look down at the bottom right corner of this diagram, you start talking about this native mobile circle, right? This user not present circle that I described earlier, all of this needs to be covered from a security perspective, in a universal architecture, you need to be able to bring your mobile into your identity infrastructure. You need to be able to bring your APIs into the infrastructure. And if you don't, the risk is severe.
So I want you to just think about in this diagram, if you didn't have this circle of a, of a core API in another domain, that if, if this core API is not architected, the way that I show it here, then what do you have to give this API? Well, you have to give this API the ability somehow to validate user passwords. And that's, that's a huge amount of authority to give to this API. It's also a huge amount of opportunity for a rogue insider. So if you do not use tokens to secure your APIs, what you've really done is created a point at every API where a rogue insider could harvest passwords. And that's an unacceptable risk in today's breach world of breaches. It means that if an attack can breach one of your APIs who has that, that directory authority, they can, you know, they can simply collect those passwords as they're, as they're sent in from the mobile.
Now at the same time, it means you have to, you know, if you, if you are not using standards, you are cashing user passwords on the device because you have to replay them to your API. So now you have two seriously risky harvest points in your architecture. Whereas if you look at this diagram, what happens is you can authenticate your partners on the left. You can authenticate your employees. You can put multiple factors of authentication together with the original password. All of that is abstracted away by your Federation infrastructure here in the middle. And then open ID connect will allow you to be sure that the identity context is correct. And meanwhile, the clients can make OAuth calls to your core API. So the reason I went through all that is, is simply so that you can see the language in use of where these standards become relevant and, and why they actually make things more secure.
So in this case, if you look at the diagram, as I've written it, there is no user credential stored on the device ever. There is an access token stored on the device, but that access token is short lived. It is abounded credential, it expires and the core API also never validates passwords. It performs token validation again against your identity infrastructure. So you no longer have to give very dangerous credentials to your core API in order to validate those tokens. And even if your API is breached, all it gives an attacker is the ability to validate tokens. It does not give them them the ability to generate tokens.
So I see it's 8 47. I think. I think we've, I've got three more minutes before, before we're gonna to address questions. Martin, feel free to come on and interrupt me a few would like to get going sooner. I'm not sure if we have a lot of questions. If you do have questions, please enter them now. But here are my recommendations for how you might be able to get to a universal SSO architecture. You do need to intro to investigate these user, not present standards like OAuth 2.0 and open ID connect. It has to happen. You need to look at how you can compartment compartmentalize your primary credentials. And I will say that that, although I focused on users, software has primary credentials too. And a lot of breaches are happening right now because nobody has set up the same standards for securing software, primary credentials as they have for securing user primary credentials. So please look at, you know, how are secrets being stored by developers? How, how are those secrets being used? Are they getting checked into source code repositories? The, these are the kinds of issues that, that we need rigor in our industry for
Please address the credential farming issue. If you haven't already users reuse passwords, we know this, you need to add at least a factor to your authentication. If all you're accepting right now is username and password, and you will let anyone in who can supply a username and password. Then you don't know who's coming through your environment. I cannot stress that strongly enough. And if you are looking for reasons to explain to your management why this is important and what the value is, I highly suggest that you read this Verizon data breach report. The important CR number here is 95% of breaches in 2014, started with a compromise credential. So if you think that your users aren't reusing their passwords, you need to think about it again. And then lastly, the future we are moving towards is intelligence. It's taking all of the factors of authentication, all of the context of all of your applications and all of your devices and combining it to be, to be smart and to see patterns in how your users are using or abusing your software. And with that, Martin, are we good to go for questions?
Yes, we are. We already have the first questions here. Perfect, Pamela, thank you very much. I will hand over what the Rachel role to me, and then we directly move into TQ and session. Correct.
Give me a second. Here we go. So as I said, we are right now moving to Q and a, and I have have a number of questions here. So if you have first questions, don't hesitate to answer these. Now the first two questions they are both, I would say rather tough technical questions. The first one is how do you implement single and on so authenticate ones and not authentication was always the same credentials in food as, so how do you implement SSO for several or based native apps running on the same device? Ah, so the, the point is that O two O and O IDC have, are open ID connect, have no answer in this requirement, access tokens per app only. So how would you resolve this requirement?
This is a great question. And it addresses a, a period of limbo that we are in, in, in the industry right now, there is actually an answer. And the answer is that the operating system manufacturers on phones have changed their, their policies around the cookie jars in browsers. So for context for everyone else, the, the reason that that single sign on is a problem on, on mobile apps is that when you, when you create a browser inside of a native mobile app, it is empty so that you do not have the ability or you historically have not had the ability to share a session across these mobile apps. And so every time you open a new mobile app, you get, you have to authenticate again. There's no idea that you already have a preexisting session. However, there, there was a standard called naps, N a P S that was set up to address this where we had a token agent on the phone that would fetch, that would allow the user to authenticate once and then fetch access tokens on behalf of all the applications.
However, this problem is such a big problem that the OS companies like apple have addressed it. So in O iOS nine, you can actually share a session context across native mobile apps. And this gives us the ability now to affect single sign on. And it, it becomes the same as SAML where you can authenticate at one app and it will create a session. And then when you try to open the second app, it will open a browser that has the same session context as the original, and that original session context can be used to, to implement single sign on. So what that means is the need for NAS has gone away, but we need to wait for applications to start using this new iOS nine functionality that you need to pop. You need to pop the system browser. Now, instead of popping the, the embedded embedded WebView, I believe I have that correct. So, so there's small changes that have to be made to the applications, but after those changes are made, we can actually start to look at SSO on mobile.
Hmm. Okay. And another question is how do you resolve as a low single logout and mixed web browser app and native app application landscapes?
This is another great question. Single logout has been a disaster for SAML for many reasons. There are in fact today in the open ID foundation, working group for open ID connect, there are three standards that are being developed for single logout. And those three standards are basically represent the three different channels by which you might need to communicate a log out request. So you, you know, in SAML, your only option was to do it via what we call the front channel, which is the a browser redirect essentially. But with the, with the open ID connect specifications, you can choose to do a back channel redirect. So a server to server call, or you can choose to do it over the front channel using embedded embedded objects in the page. So I would highly encourage you to go look at the open ID at open id.net/connect. And you'll see there that, that these protocols are, are, are doing very well and crawling towards ratification.
Okay. Pamela, you mentioned the account chooser. So, so who's standardizing this or is it part of another standard? So where does it belong?
Account chooser is also part of the open ID foundation. And you can see more information there@openid.net slash AC for a camp chooser.
Okay. You also brought up the topic of Fido as pH Alliance was there standards. So I think it's, it's, it's interesting to see how organizations are, are starting to, so particular vendors are starting to support Fido Alliance. So, so what is your perspective on the, the future role of the Fido Alliance standards?
I think, I think Fido is a critical for our industry, but it, it is still quite young. I, at the RSA conference in San Francisco this year, Microsoft announced that they would be supporting Fido 2.0 in their windows architecture. And that's a pretty big deal. However, it's, it's still forming, but for those who are not familiar with Fido, Fido is really the goal of Fido is to standardize the authenticator to, to server interaction. And by server, I mean, you know, the there's often code running on a device and that code on the device needs to call multiple authenticators. And today it's, it's a very proprietary thing, right? You basically have to, to go through the OS. So the idea is that any piece of code running on a, on a device could call any authenticator in a standardized way.
I have to admit I'm also a strong believer in that. And you know, when I look at all the discussions of guns through and how, which, which strong authentication technology to use, where then, then I think moving to standards here is one of the most critical and most promising areas in the broader identity and access management space. So if we succeed in that area, we clearly have a, a, a good way of improving and increasing our security massively.
Yeah, I agree. And I think from a privacy perspective, one of the best things about Fido is that they have a, you know, one of their credos is that they keep the, the data local on the device, right? So by using a standard, for example, to look at a biometric signature, you're, you're pretty well guaranteed. You know, you're, you're exchanging a local biometric signature for keys managed by Fido. And I think that's valuable for anyone who's worried about, you know, fingerprints leaving their device or biometrics of any kind leaving their device.
Exactly because fingerprints are out to change in contrast apart passwords.
We,
Okay. So I think we've gone through the questions we had here. We are anyway, close to the top of the hour. So Pamela, thank you very much for your presentation for answering the questions so much on detail. Thank you to all the attendees for listening to this call webinar, hope to have you as an attending. One of our upcoming webinars sooner. See you at our dialogue next week, our DSE in May, 2016. So thank you and goodbye.
Thank you everybody.
