Oktane19: Securing Omni-Channel Experiences: Best Practices from the Real World

Sparube: Thank you so much. So as Tammy mentioned, I am Sparube. I'm a senior product marketing manager for customer identity here at Okta, and later half of this section I will have Shay Logan from Rent-A-Center join us and tell us some of his stories from the trenches. Our legal team, spent a lot of time thinking through this slide and putting a lot of interesting content. I don't want to bore you guys through the details, but there's a lot of interesting stuff and I'm obligated to show you the slide. So for this session we have an interesting plan securing omni channel experiences, right? So on the first section of this presentation, I'm going to give you guys some of the insights and stories that I have and some of the trends that I've seen from talking to customers across the board.

Sparube: And the second half of this presentation, you're going to change gears and Shay is going to take this down and as a practitioner and give you guys all the details behind his experience implementing some of the pieces that I've seen across the board.

Sparube: So as you know, it's been about 12 years or 13 years since the iPhone was first introduced. And since that time, the number of devices that each of us own, the number of smart connected devices that each of us own has exponentially increased. I read a recent survey that said that an average user owns about 12 phones, 12 connected devices and those number of devices are exponentially increasing year on year.

Sparube: But if you dig deeper, what's even more interesting is that it's not the number of devices, but it's also the amount of time spent on these devices. It said that the average user spends 10 additional minutes on a non desktop device. So if you are a business in this room, making sure that you can reach your customers across all of those channels that they spend their time on is kind of business critical.

Sparube: Today, it's the smartphone and the tablet in the future we expect to see connected devices such as an AI or screen less experience through an Alexa device or Google Home in which users connect and access your service. But a critical part about building trust in this omni channel world is ensuring that you have a secure authentication experience as users transition between the different channels in which they might access your service. So it is very important to understand that identity and authentication become critical elements as in this journey. It's not just from the aspect about the who is this user, but it's also critical as part of the security journey that we have the right sort of mechanisms and controls as users authenticate across different channels.

Sparube: And as I say, numbers don't lie. And what you have seen is that as over time, the number of users accessing these omni channel experiences has exponentially grown, right? It's predicted that in the future, about 90% of users will have gone to an omni channel experience before they buy something in a retail store, for example. So it's predicted that this number should reach about 1 trillion dollars in revenue pretty soon. Now, that's pretty rosy numbers if you have not paid attention for. But what's interesting is that the numbers associated with fraud also tend to follow this as users migrate towards omni channel experiences.

Sparube: It's predicted that fraud in this channel is expected to grow exponentially and the cost to solve some of the fraud and security problems is actually about 3 dollars for every dollar of fraud that you see. So you're spending at least three times more money as you try to stop fraudsters from attacking you across all these different omnichannel experiences.

Sparube: But when we dig one level deeper behind the numbers, what we see is that trust, which is the key element that user's expecting an omni channel world is frequently abused by compromising user identity. And this happens in three different ways. The first way is essentially by leveraging stolen identity where good users' data is taken through data breaches such as the Equifax, Breach Target, Home Depot. We don't need to look far to find all of these big breaches that happen. By taking the PII information that's exposed in some of these breaches, attackers take that information and concatenate and construct synthetic identities on your platform. That's the first time.

Sparube: Second, we have the problem of account takeover where the good users that you spent all the time and effort bringing onto your platform, their credentials are compromised through a third party data breach potentially. And that information is accessed and used by attackers to get access to a user's account. And finally, especially in an omni channel world, what we see is that stolen user data is another quick reason or key reason why users come onto your platform to get access. So in many cases we've seen businesses while they think about the main doors to the web and they set up all these additional APIs, they find that insecure APIs are an equally open door for attackers to come in and get access to user data that's stored in that account.

Sparube: So if you're a business leader, if you are a product manager or if you're a developer sitting in this room, how do you think about securing omni channel and securing trust in this world? We think it's more than just conveying a few icons that represent trust and safety. It's not just the icons on the checkout page or a trust and safety page, first of all it starts off by understanding what are the key requirements behind this.

Sparube: When I see customers talk about securing their omni channel experience, what I realize is that it comes down to three key requirements. First as the security requirement, ensuring that you have the right controls that are appropriate for the different channels a business might offer and ensuring that the authentication experience is secure. The second part of this journey is ensuring that you have a consistent view of the user, independent of the channel they came in. If you think about it, that's the marketing play. And the third piece of this is the user story, which is that you need to enable your users independent of the channel that they come in.

Sparube: So these we think are the three fundamental recurring themes that customers ask. So how do you go about securing trust in an omni channel world? I think the first element in this building block is having identity proofing. So just for some definitions, identity proofing is the bridge that connects users offline identity, your driver's license, your passport, your college ID, your military service ID to your online digital identity. And having some sort of a proofing mechanism as users come onto your platform is critical in stopping fake users from registering club platform. And this is where an identity platform with extensibility builtin can help you deliver on that journey.

Sparube: And it's also very important to understand identity proofing is not like a single solution. Every business has different requirements for identity proofing. It could also mean if a retailer, it could mean something like a device fingerprinting check to verify the reputation of that device. Or it could be something like checking the reputation of the email that was used to register the user onto your platform.

Sparube: It's very important to understand that when it comes to something like identity proofing, independent of the channel, you need to factor build the channel in which users are coming on your platform and the solutions that are appropriate for that channel. So the other one piece as part of this journey to consider is that when it comes to identity proofing, it's not a point event. It's not like filing a credit application. I come in, fill out a big form of 20 different forms and hit submit. It could also be done in a progressive manner. We saw some of at the demo today in the morning, but you could also progressively gather user information and use that information and check reputation checks. For example, I come in, I registered with the email, create an account. Now you could check with the email reputation service to check the reputation of that email.

Sparube: Subsequently when the person comes in and decides to file a loan application or for a credit card, you could take that information and then do a full heart identity check as part of bringing them on your platform. Now the key thing to remember is that when you think about an omni channel world, having the right sort of ID proofing is very relevant and it requires a lot of strategic thinking. So with that, hopefully with the right solution in place layered on top of an identity platform, you have the first fundamental building block in stopping fake users.

Sparube: The next piece of this journey is what we call as the privacy journey. It's very important to understand that users trust their data in your service is secure from compromise. We know that in today's world, when you combine our users online activities, whether the sites we visit, the items we added in the card, the items we would move from a shopping cart, for example, the places we think about visiting and searching and on a search bar for example, and you combine that with offline activities such as the locations we went to. It provides and is a very powerful tool for companies and governments to understand what the user is up to.

Sparube: Ensuring that you're transparent about the users' data collected and you're ensuring that, you're ensuring the right sort of controls when you want to access that information is critical in ensuring that build privacy. So as I think about the privacy challenge in an omni channel world, think about not only the data that you're gathering, but also the consent and the permissions that you're asking for the user when you gather that information.

Sparube: The third element that's very critical building block in this journey is what we call as account security. Now, in an omni channel world, account security is a very complex discussion, because when you think about what's the cost of not having good account security, the result is account takeover. And attackers are getting more sophisticated not only are they leveraging credentials that are available in our credential bridge, but they're also leveraging your other doors that are not as secure sometimes. So think about your password reset flow, think about your account recovery flow or in an app like they're getting even more sophisticated, the leveraging your call center to actually socially engineer your call center and take over your account.

Sparube: So the story is that, the bottom line is that attackers are getting more sophisticated and they're looking for the weakest link in which they can get access to your account. So when you think about securing your channel and your account thereby, it's important to think about what's available. So through, let's say for example, if it's a web property, usernames and passwords are very relevant. But if you think about something like a mobile device where you have the luxury of biometric authentication and modern standards such as WebAuthn leveraging those standards as users authenticate into your platform is very critical in stopping account takeover from happening.

Sparube: The fourth element in this journey is essentially stopping fraud. As I mentioned earlier, fraud can happen from multiple different channels and attackers are looking for the most insecure channel that you might have. It could be like a connected device or it could be like a mobile phone, but also your web experience as well. So users, when they come onto your platform and good users create an account they trust that all the information stored in that account post authentication continues to be safe and secure. So having the mechanisms to stop fraud is very critical in this journey.

Sparube: And how do you go about stopping fraud? I think there are a of the number of different promising approaches to stopping fraud. But solutions such as MFA that are very useful in this front, can help stop some of the fraud that you might see at time of payment for example. But also additional solutions such as continuous authentication, ensuring that the biometric data that you can capture behind the scenes or the silent attributes that it can capture behind the scenes still validate that this is the real user is critical in ensuring and stopping fraud.

Sparube: So clearly using these four elements, you have some of the key building blocks to stopping fraud. And don't get me wrong, the omni channel experience offers unprecedented opportunity for your business. It is new ways to engage and interact with your customers, but it also offers unprecedented risk. It's a way in which attackers will look for the weakest door to get into your service. And by thinking about those four key pillars, you probably have a good chance to stop with these attackers.

Sparube: Now that's enough of me talking and synthesizing and giving you a lot of insight about what I've seen with customers. Let's shift gears here, take it to a different level and see how someone took this on in the real world and solve some of those challenges. So Shay from Rent-A-Center is going to talk to us about his journey in securing in his omni channel experience. Thank you Shay.

Shay: Good morning. I would like everyone for coming and I would like to thank Okta for having me. I'm an application development manager at Rent-A-Center. So those that don't know, we're both a retailer and financial. So we kind of bridge both pillars. People put items on rent, then our revenue is collecting the rent going forward. So payments are very critical to our business. I have both rentacenter.com and the Rent-A-Center mobile app. So when I first started at Rent-A-Center I was tasked with delivering a mobile app to the enterprise.

Shay: So one of the first questions I asked myself is should we use SAML versus OAuth? The current rentacenter.com is using SAML which got a long history that isn't part of this presentation. But I took this as a fresh approach to re look at that conversation. So I want to give you some of the thoughts and questions I went through as I asked myself that question. If you're using enterprise then in a kind of single sign on, then SAML is your tool of choice.

Shay: If you're providing access to any resources, then I would lean towards OAuth. If you're doing any kind of integrated access like through a portal or that kind of stuff, then I would go back towards SAML. But if you're using any mobile application, I would highly recommend you lean towards OAuth. And just a little slide to show you kind of how I broke it down. If one user in the transaction is an enterprise than use SAML, for anything external or mobile, I would lean towards no OAuth.

Shay: And to kind of continue what Sparube was talking about balancing the security and the ease of use, it's always a balance in software development. There's very few clearcut answers. It's always a balance. So we wanted to have high security because we collect payments, a lot of payments and because it's over the life of the rental agreement. So we have to have a good user experience in this because we need to keep our customers coming back. It's just not a sale for us. We were in a business.

Shay: So we wanted to have single users between the website and our mobile applications. We use the same Okta tenant. And in OAuth and OIDC connect, which I'll go into shortly is the output of the authentication is a concept called the JSON Web Token. This is how long the user's logged in for. And so to balance the security, this should be set for a very short time because that is used for access to our back end resources, which I'll show in order to balance that there's a concept called a refresh token, which allows you to continuously extend the life of your JWT. That way you can keep your user logged on for long periods of time even though they're not.

Shay: And then another approach I took in, in OAuth you typically have a client secret for your application in a mobile application, please do not do this because your application can be easily decompiled and that will leak and that's something you don't want out in the wild. So what you can do is you can use a concept called the proof key of code exchange. And I'm going to show you where that is as you effectively generates some random characters, you hash them, you send them in, and then you've sent a verifier later in the flow, which I'll show in a little bit.

Shay: Then the next concept that comes up is, OAuth is primarily an authorization mechanism. It doesn't define the authentication it leaves each provider to do that. OpenID Connect bridges some of the authentication kind of holes in OAuth, and it also allows you to use that PKC that I talked about the proof key of code exchange. And how it works is there's two different channels. It's the front channel and the back channel and there's reasons for that and I'll show them to you to now.

Shay: The front channel takes place in a web browser, whether it's a web view, if you're using a mobile app or the mobile browser, it's your choice. We leaned to use the of web view that we're not kicking them out and have them and then go back to your mobile app. If you're using social login, which is another thing that OpenID excels at, it gives user trust to see your Facebook, your Google login. So when they log in and they enter their user credentials, it is in the browser.

Shay: The back channel takes place internally. You're making web service calls and if you're familiar with it, these are done asynchronously, so keep that in mind in your button states, put them back to the indicator. Don't assume it's done and then have the user trying to interact with it before it's done because there's a few different conversations that are taking place between your application and the identity provider. So let me show you the flow that takes in. This is the code flow or the authorization flow in the mobile application, so when you launch the application you may bring up your login page or if you're using a refresh token. You may check that. If it's not there then you bring that up. But you launch either the embedded web browser or you kick them out to the mobile browser. They enter their username and password when you authenticate with your identity provider, which is Okta for us.

Shay: Then you get a token has returned. This is happening in the front channel. Then your second step is, this is also in the front channel is you take that token and you exchange it for OAuth code. If this step is you're sending in that hash random character strings for the PKCE or your other called Pixie if you read online. People like to abbreviate, it makes stuff easier to pronounce. So that has done in the front channel as well. Then this is where you pick up from the back channel is you take your OAuth code excuse me, and you exchange it for your JSON Web Token, your JWT.

Shay: Then once that is handed back to you validate it, make sure it's against the issue that you're expecting you do not want a man in the middle intercepting that and giving you a fake token. And then I'll show you the structure of it. Then we take that JWT and then we're using an enterprise service bus for our end point and there's no service accounts in the mobile application because this is another leak point for a lot of people just have a service account with basic authentication.

Shay: We take that JWT and we pass it to our ESB and the ESB authenticates it and authorizes it based on JWT that's parsed in. They can parse it internally and validated it and or they can delegate impact to the IDP and verify it that way. That's the more secure approach. Some people split in the middle where you check half of them internally and delegate half of them back out. That way you've got 50% chance of catching one if it's been revoked for whatever reason.

Shay: And then another concept the OpenID Connect gives you is a concept called custom claims. These are extended attributes of the user's identity. We use it for different data points in that its returned in the JWT, you can use account numbers, telephone numbers. If you're trying to roll your own multifactor, please don't. But you can have as many of these as you want. Just think of them as extended attributes to your profile that's kept track on your identity provider.

Shay: Then if you're wondering what the JWT looks like, this is one that I generated. It looks like a bunch of random alphanumeric characters where there's a structure to it. Once you parse it, which is easy to do, there's libraries to do it or the structure is not hard to do. This is what it looks like. It's parsed. It gives you the issuer, the expiry time, which is a key point that I wanted to call out. That is a hard expiry time when it's issued, it's issued for ever how long it's defined. It's not like a web session that keeps getting extended each time you touch it. So if it expires in five minutes, expires in five minutes, it won't be extended.

Shay: So if you're viewing a mobile application, I would highly recommend you set a timer and manage that that way. So as you approach the expiry time, you can trigger that exchange with the refresh token and get a new fresh JWT and your user is still in business. Then you can manage it if that's the timer, if they go to the background or they bring it to the foreground. Then when you store these, make sure if you are using the refresh token, please put them in secure storage, Keychain for IOS or the Keystore in Android because that can be used to generate a new JWT.

Shay: Then if you have any custom clients will be returned in those, as you can see this SEP is the offline access. That's the refresh token. You have the conical user ID from your identity provider, which is the UID. Those are defined by the Spec and there's some other stuff that's defined by Spec as well. So I wanted to share some resources that I used when I was going down this journey. A Walk To in Action is a really good book. I highly recommend you look at it, as well as Okta's developer resources. That RunKit is a very nice thing to do to generate your pixie codes when you're working through your development because they're a little obtuse. Anyway, I'll turn it back over to Sparube

Sparube: Hey, thank you so much. So hopefully all of you guys got a sense of appreciation and complexity in world while trying to secure your omni channel experience. Remember that this is not a point solution. This is really a journey and you need to think about this journey in terms of all the different elements. That was the complexities Shay went through when he tried to build out security from an authentication standpoint. But additionally you need to think about the identity creation process as I mentioned earlier, we need to think about privacy, but you also need to think about fraud. And when you combine all these four elements together and you layer below thoughts about the user experience, you really have a solution for building for trust without compromising security in the process.

Sparube: So with that, I want to open up the floor for more Q&A. But I also want to remind you guys that we have a mobile app. If you don't have it, I highly recommend to download the app and rate the session, your feedback matters a lot for us. Additionally, I want to call out for some awesome sessions that we have planned. I know I gave you a lot of high level elements that, how to think about security and trust and privacy. A lot of interesting concepts, but these three sessions are highly recommended from my end.

Sparube: John and Wills are going to talk about the customer identity roadmap. Not only they're going to talk about some of the elements that they built and accomplished in the last few months, but they're going to talk about some of the other things that they're thinking about in the year to come. Nate, who's our product manager for the developer experience, is going to talk to you about some of the SDKs and some of the developer experience kits that he's building out. So when you think about STKs for Push, think about all of those things will be there.

Sparube: And finally, Tanaha and Alex Bobi are going to talk about our security roadmap. So when you think about account security, building better security, a lot of the topics that they're thinking about and trying to solve in the year to come are going to be covered in that session. I highly recommend attending these three sessions, but also in the process I want to open up the floor and take any questions you guys might have.

Shay: The authorization services Okta, we're using the OAuth flow, so all the IDP slides.

Sparube: Yeah, this one.

Shay: Yeah. These are all hitting IDP is Okta. It's just the identity provider. And once we have the JWT then we parsing it to our ESB who is validating it and making a call back to Okta as well to validate it.

Sparube: I think if you have additional questions, we have a blog post on how to think about authentication authorization. It's frequently conflated. So there's a simple blog post on the Okta page, I highly recommend looking about that til you get more detailed info.

Shay: Yeah. And I have a prototype app if I can share as well.

Speaker 3: So thank you for the detail explanation here. What I'm trying to say is that between the SAML and OAuth like what is the preferable approach? I know it depends on the use case, so-

Shay: It depends on the use case. I selected for the mobile application we're using OAuth, for rentacenter.com it was done before I got there. They selected SAML because they were most familiar with it. If the choice was mine I would have used an OAuth, an impulsive flow probably for OAuth for that.

Speaker 3: Is the industry moving from SAML to OAuth?

Shay: It's I have a backlog of, yes, it's on the backlog. My backlog is a very long and so.

Speaker 3: Thank you.

Shay: You're welcome.

Speaker 4: We have a question at the back.

Sparube: Yeah, I think we have a couple of questions in the back, so go ahead.

Speaker 5: Yeah, hi my question was about the balancing security and ease of use. We're also starting the Okta journey and we have both internal requirements for the internal apps and we're going to be using Okta also for client. And my question was the criteria used to go with one instance or tenant versus having one per client, one for internal.

Sparube: So if I understood your question correctly, your question was around what great apps do you make between customer identity, like user experience and workforce identity. Did I get the question correct?

Speaker 5: Yeah and Okta.

Sparube: Yeah. I can cover some of that, but maybe Shay you want to open up and say how-

Shay: At Rent-A-Center we have three tenants. We have an internal for our employees, it's integrated with active directory. So they log in, they hit our tenant.okta.com and they log in and they can access like a jillion apps that are all integrated. Then for our external facing, we have another tenant that's used for the mobile application and rentacenter.com there's shared tenant, so the users you registered one, you can log in with the other and vice versa. It seamless. Then we have another business unit and so we have a separation. So if you're a customer and both you have two logins. We had a legal and operation requirement to keep them separate. So that was for the third tenant. So I would recommend just me personally, I would recommend you have a tenant for internal and a tenant for external.

Sparube: So I think to add to that I have customers who have a huge number of tenants depending on the business complexity. So especially if your business spans different regions, has different legislative requirements, that's pretty common to see breaking it down based on different tenants. That's one common scenario that I see. But also you had a question about the user experience versus convenience between workforce and customer. Right? So when it comes to workforce, let's be honest, you don't have much of a choice you work there, right? You got to follow what the I.T team says. So if it's 2FA, 2FA everywhere 2FA at an app you basically make the choice.

Sparube: But you should remember that behind the scenes Okta gives you the controls for you to decide if it's necessary or not. So if someone's an employee is trying to log into their work using the corporate issued laptop inside of your corporate network, there's very little need for MFA, but if you deem it necessary based on your business needs and the org for example, that the person works in.

Sparube: So someone in engineering who trying to get access to a code base might be more high, as in you might want to have additional security, for example. That's typically how it is done, on the consumer side. This conversation is actually way more nuanced than what we can actually have in the session, but basically to think about it, two factor is not most ideal situation or you want to be very judicious of how you deploy it.

Sparube: The question for you is, how do you be so judicious? Right? And that's where something like an adaptive or behavioral authentication can come and really shine and reduce the number of instances you're prompting your customers for MFA. So things like, hey, if the user is logging in from this known location, their known MacBook, you don't need MFA. But when something is off or they're coming in from a risky IP address, right? That have previously someone on the Okta network has seen as being malicious, that's a good reason why you should probably prompt for MFA.

Sparube: The one exception to that story and that question that you have is like we obviously know like banking applications for example, there's compliance reasons, insurance also has certain compliance requirements. Healthcare similarly for those you have customers willing to put up and have MFA in the experience. So, it's a bunch of trade-offs between convenience and user experience. But by leveraging things like behavioral authentication, you have the ability to like kind of reduce the number of times you're prompting your users for MFA.

Sparube: And that can be a very powerful driver for better experience. In fact, I know of one VP of product who said that she was trying to be secure and she's like trying to actually improve the net promoter score of her product area, and she was using adaptive MFA to reduce the number of times she was prompting users. So it's a pretty complicated topic. I can probably take like 40 minutes and going over about, but there's a lot of detail there that are highly ... and also a lot of exciting areas that new protocols and technologies like we're about 10 that can really revolutionize how we authenticate into web applications that can really help improve the experience. So that's a lot of talking from me. So I'm sorry I'm being blinded by the light, but go ahead.

Krishna: Okay. Hi, thank you for the great talk. I am Krishna and in my organization we are also embarking on revamping our consumer IAM space. I had one question on the authorization piece. I understand we have multiple options for authentication like 2FA and MFA like you mentioned. When you have scenarios where you have your external consumers authorize multiple apps internally, whether it's workforce or consumers, how do you guys use any custom or tradition frameworks or does Okta have any frameworks which I could leverage to authorize access for my consumers?

Sparube: So you're basically asking about how do we build out an authorization policy framework for a different user groups, right?

Krishna: Correct.

Sparube: Yes, we do. But I am not the subject matter expert on that so I'll be giving you wrong advice. But we can connect offline and I'll put you in touch with the person who can give you the best practices there. Or stop by the Okta booth downstairs and we should have some subject matter expert there who can guide you through.

Krishna: Okay. Thank you.

Speaker 7: Yeah. Hi. Thank you for the great talk. So my question is within the enterprise, if I have a lot of applications that need to be secured with a seamless identity management, do you see a need of using OAuth for that purpose with Open Connect? Or can I simply go with simple password based authentication and then grant an access to all applications seamlessly?

Sparube: So I'll give you the point answer, standards, standards, standards. That's the best approach to go. As in there're a number of security reasons that'll take us a lot of time but standards it's as in a lot different applications that you might need to connect support. So you're not using something that's proprietary. But also additionally, when you think about the security risks. Your security team will probably do an audit and say like, no, don't do that. So without going into the details there, my personal recommendation is always go with something like OpenID Connect and OAuth to drive your authentication experience standards always. Yes. Good. One second let him the microphone.

Speaker 8: You mentioned about MFA, is it pre-configured or? Also you mentioned like if you are logging into other computer or some other device, you can change the MFA isn't it? How is it possible?

Sparube: So, one followup question is this for a workforce use case or is this for customer use?

Speaker 8: Customer use.

Sparube: So, when it comes to MFA, Okta's MFA solution is essentially a platform approach. So we give you a range of MFA options as an admin that you can pick that's most relevant for you. So what our recommendation is that there might be scenarios for customers where security question or a knowledge based question is appropriate and enough, that's the risk in is very minimal. So go with that. But if you're a banking application, you're a financial application where the stakes are way higher, there are higher assurance of factors that are in play that Okta offers that you can just turn on, including biometric authentication.

Sparube: Now on the other piece in this decision is also understanding user risk groups. So good practitioners break the users into high risk groups. For example, Beyonce is on your platform. What do you do? She's going to be attacked everyday on Instagram, for example. So you want to probably put these high risk individuals in a higher security group and force them, hey, anytime you log in, go to MFA. Right?

Sparube: So, it involves you looking at their security risk profile and then putting them in appropriate groups. And we give you all the policies to drive both enrollment of the second factor, but also like the enforcement, where do you want to enforce? Do you want to enforce it at the app level once or do you want to enforce it multiple times when they log in, do you want based on time. There're a number of different options that the policy engine can give you. This might be an appropriate approach based on that risk group for you to factor. Any other questions? Cool. Going once, twice and ... oh, there is a question at the back.

Speaker 9: Here you go.

Speaker 10: I don't have a question per se it's more of a small announcement. So I'm a product manager at Okta and I'm working on an area about growing SAML user basis by 20 to 40% using external identity providers, which seems like a relevant area for this room here. So if anyone wants to talk about that or learn a little bit more about some of that stuff, I'll be hanging out in the back and please come up to me and I'd love to talk to you guys. Sorry about hijacking that, Rube. 

Sparube: No. All good. Is there any more questions?

Speaker 11: Just one quick question. You mentioned privacy obviously is an important part of the journey for a customer or consumer identity. Are there any tools or integrations that Okta has done for example, with like a one trust privacy platform or other to trait that fully integrated privacy consent journey?

Sparube: So a couple of things, Okta has some privacy management tools in the product itself. If you stop by at our booth we can show you some of the tools and capabilities that we have that we can show you. Additionally we're very open minded about partnering as in we are actively looking for partners in the segment and we have partners too. So, if you come down to our booth I can talk to you in more detail about some of the interesting concepts we're working on on this front or if you've done a lot of progress here in-house, but also we understand privacy is a very complicated concept. There's a lot of different use cases and scenarios. I'm coming in from Russia. Privacy and consent looks different. I'm coming in from China, it looks different. I'm coming in from the US, where still I think it might even look worse once you have CCNA and all these local regional privacy laws that come into play.

Sparube: So we have a solution in place or we have an approach in place that I can talk to you about and hopefully that'll meet your needs. Cool. Yes.

Speaker 12: A question for Shay. When you use the back office or call center to manage identities, maybe force password reset or make those kinds of changes, do you use the Okta GUI or did you code your own kind of call center app using API calls?

Shay: We have a custom login page and a custom password reset page for a few different use cases, which I really don't wanna go into, but it's custom and then they're using the Okta APIs to do it.

Speaker 12: Thank you.

Shay: You welcome.

Sparube: Yeah. There's another question over here.

Shay: Yeah. In the white.

Sparube: Gentleman in the white man. Okay last question.

Speaker 13: So if I have a use case like Google where you have a centralized authentication but you provide a seamless experience to different Google applications like Gmail, YouTube, whatever the Google has access to, does Okta has anything kind of a package that we can leverage to implement?

Sparube: So you're basically asking about Google as an IDP provider, right?

Shay: Yes.

Sparube: So the gentleman there is your ... like go give him a hug, he'll give you all the details. We have over 30 different integrations for these different IDP providers. It might be Google in the US, it might be a different vendor in China, but as long as it talks standards, we have a lot of them and Norish has worked a lot in that front. So have a chat with him he'll tell you a lot of interesting and exciting stuff there.

Speaker 13: Okay. Thank you.

Sparube: Cool. So I think we're end of time I can see the buzzer going off here. So thank you so much for attending our session and giving a lot of discussion and interest in talking points here. So thank you.

Shay: Thank you very much.