Oktane18: Leveraging the API Economy to Drive User Adoption and Growth

Minusha: Good afternoon. I'm Minusha Gueshing , a sales engineer with Okta. Today we're discussing leveraging the API economy to drive adoption and growth. So, to give an introduction, as you already know today, every company needs to be a technology company. Even traditional businesses, even if your product is not tech focused, you still need to use technology to not only thrive, but survive. Especially when you end users expect a seamless customer experience that evolves quickly with their ongoing needs, and your developers expect an ecosystem that allows them to build and iterate quickly.

So this is where API economy comes into play. The Gartner quote here perfectly describes what an API economy is. The API economy is an enabler for turning a business or organization into a platform. So what does that mean? To answer that, you will hear from two organizations who have leveraged an API economy to accelerate the growth of their user base and the relationships they have with their customers, end users, and business partners. They will share replicable models that you can use to not only capture quick wins, but to build a future-proof program. First we have Crystal Yen and David Koe from product and user experience at US Digital Service. That's an agency that uses design and technology to deliver better services across the federal government. You'll hear two case examples from the Center for Medicare and Medicaid Services, where they created an API services infrastructure that improved the end user and developer experience, driving adoption through their APIs and facilitating hundreds of developers to build applications on top of the APIs. Please welcome Crystal and David.

Crystal: Great, thank you. So, for those of you who aren't familiar with us, we're here from a group called The United States Digital Service. And we're a start-up essentially within the federal government. We are founded four years ago, in 2014, during the healthcare.gov crisis. When someone asks, instead of having a bunch of people who know technology come in at the last minute to fix a problem, what if we had them within government at the start so that they could really help develop new services?  And so we have teams at the agency where we're at, the Department of Health and Human Services. We also have teams at the Department of Defense, the Department of Veterans Affairs, and the Department of Homeland Security, as well as a few small projects at agencies like the Small Business Administration. And our whole mission is to take human center design expertise and modern software development practices and bring them within government to deliver better services to the American people.

To give you a quick preview of what we're going to talk about today, I'll first tell you a little bit more about our team at the Department of Health and Human Services, what our values are and what our goals are. David will then walk you through a case study of a project we worked on called, The Quality Payment Program. And then I'll tell you briefly about another project called The Blue Button API. And finally we'll leave you with a few resources that you can take back to your organizations to help launch APIs or to just help bring more modern technology practices into a large organization. So, who is the US Digital Service at HHS specifically? Well, we're a team of technologists and designers and healthcare policy experts who truly believe that the future of healthcare should be focused on empowering doctors and patients. When we worked on a number of projects, we realized there's quite a bit of disconnect, especially when it comes to implementing technology in government.

Oftentimes you're working with certain requirements that are essentially set by laws that were created a couple years ago. And we realize in order to make sure that the right services are being delivered, that the right data is getting to the right person at the right time, we had to have technologists and policy makers in the same room and working collaboratively with best practices from both disciplines earlier. And if we did that, if we were able to work together to advance this mission, we would be able to fulfill that vision of empowering doctors and patients.

So, why don't I tell you a little bit more about one particular program that we work on, which is Medicare. We're the largest healthcare insurance payer in the United States. We serve 55 million beneficiaries, anyone over the age of 65. And about two billion dollars goes through Medicare every single day, which means that overall we comprise about 3.5% of the US economy. This means that we have tremendous influence, not only on our end users, our beneficiaries, and our providers, but also on the healthcare industry overall. When CMS decides to really push for a particular technology standard or development, we really set the standard for the market to demand the same from other payers in the healthcare system. And now David will tell you a little bit more about a project we worked on called The Quality Payment Program.

David: Thank you Crystal. So, my name is David Koe. I'm an engineer at The US Digital Service. And I'm here to tell you a little bit about how we used APIs at The Quality Payment Program to improve the healthcare system. So, what is The Quality Payment Program? Well, you may have guessed from what Crystal just talked about, it's related to Medicare. And actually it's related to how we pay out the money from Medicare.

If you think about paying out two billion dollars’ worth of money to healthcare providers like doctors, hospitals, home health organizations, etc, that has a big impact on how people actually decide to do healthcare, and what the quality of that healthcare is. And the theory behind The Quality Payment Program, which was established by a 2015 law called MACRA, designed to update the Medicare program and how it pays out money. The theory behind this program is that if you incentivize and support doctors who are actually demonstrably doing better jobs delivering quality care to their patients, then that will improve the quality of healthcare in the United States in general. And so, how do you actually do that? Seems like a great goal, right? It would save lives, it would make people healthier. But to actually do that, what you'd have to do is you have healthcare providers figure out these specific quality metrics. There's hundreds of quality metrics. An example of a quality metric would be like, if you are a doctor who sees patients with diabetes. And patients who have diabetes are also at a high risk for glaucoma. So you would need to make sure that they get referred to eye exams to prevent them from getting glaucoma and becoming blind. This is one way in which you as a doctor might actually improve the quality of someone's life, improve their health.

So the quality metric for that is basically, of the patients you saw who had diabetes, how many of them did you refer to and actually went and get eye exams? And so you record that, and then you would submit that to The Centers for Medicare and Medicaid Services. And so basically if you submit that, and we look at all of these hundreds of metrics that are all these objective metrics that we can look at and say, this is actually high quality medical care, especially compared to everyone who submitted, you would get a pay bill. You'd get a positive payment adjustment, which gives you more money, supports you as a healthcare, and incentivizes you to keep doing that good quality care. If you don't actually submit anything to us at all, or essentially just submit stuff that indicates you're actually not doing that good of a job making patients healthier, then you would get a negative payment adjustment.

And this is a great model and theory. In practice it has one big issue that we had to address when we were building the system out. And essentially what that problem is, is if you go to your doctor, and your doctors is spending a lot of time thinking about why are you sick? Well I remember, you know, David, and I remember that he has this, you know, history. They spend some time thinking about that, how they can make you better, following up with you afterwards, they're not spending that time gathering up all that data that they need to submit, and aggregating it and actually submitting it. Whereas the person who maybe makes you wait in the doctor's office and sort of sit there, and they're like worried about all the paperwork you fill out, that might be the doctor who you probably don't like and maybe isn't making us healthy who actually gets the stuff submitted.

So the problem is, if that doctor decides to make that trade off, they might get a negative quality adjustment because they didn't actually get the chance to submit the information that says, "Hey, I'm doing a good job." So that's the problem that we wanted to fix. Because it undercuts the whole theory. If it's hard to submit, if it's burdensome for providers to submit this information, then the whole theory of improving the US healthcare system and saving lives doesn't work.

That's where we get to the technology. So in order to do that, we build a website. Actually we replaced three websites, which were hard to use, hard to log into, which is one of the points of this conference, and actually just hard to figure out what you were even supposed to do, with a single website that covered all of the things that you would need to do on those three different websites, and also explain to you what it was you actually supposed to be doing on them. And we accomplished building this website by essentially doing a lot of user experience. Finding out what are the pain points that people actually run into when they're trying to submit this quality information. And here's where we found out the opportunity to leverage an API. Because we found out that there's a whole portion of this healthcare providers who don't spend all the time figuring out how to jump through hoops and aggregating this information, they paid someone else to do it for them.

And there are a whole set of companies called healthcare registries that has spent a lot of time and effort thinking about innovative ways to actually set it up so that instead of having to gather and record all of this information separately, and make you sit in the office and fill out paperwork, that can be built into how healthcare providers work, how your doctor works, how your hospital works. But of course those registries also run into all the same issues where it's not actually that easy to submit stuff to CMS. So we decided that we would build out an API first. Take an API first approach, which meant before building out this whole nice UI that you see in front of you right now, we would build out a clean, well-documented, with developer documentation, easy to access through an API token, API, publicly accessible. And we would build our API on top of that. But we would give out access to that same API to these registries that are actually building and innovating new healthcare, new ways of gathering and reporting this information that we may not have even thought of, or we couldn't of thought of. Creating this innovation that basically could completely reduce the burden for doctors to submit this quality information, and make sure that the doctors who are doing the best work are getting credit for it.

So how does this actually work? We got some good feedback from the users and the developers who use this API. From the user of the service itself, they're actually afraid they hadn't actually submitted their information. Because it was so easy to submit the information, that they thought there was going to be a lot more steps. They thought they had screwed something up. So they called the help desk. Am I really done? Is this all I have to do? And then on the dev tools website, developers said it was a quantum leap forward from what CMS had exposed in the past, which was basically like a not very well documented file format without really any validation, without a clear mechanism for authentication. We gave them a clean API with clean developer tools. And not only do we have qualitative information, but quantitative information.

Almost a sixth of the submissions that we gathered overall, came through this API that didn't even exist the year before. The concept of the API didn't even really exist the year before. So right out of the gate we say a huge number of submissions coming through this, you know, market that didn't really exist-, I mean, it existed, but there was no one using or thinking about using APIs to submit this information. But since we did the user research, we found out that the need was there. And so creating the right API can create the opportunity for your organization, for your customers, for your users, to drive huge innovation whatever market you're in, on top of your platform. Our platform and our market, what happened to be the US healthcare system. So luckily we're able to not only try and improve the healthcare system ourselves, but empower our partners in private industry to also push forward and innovate to improve the quality of health in the United States.

So, now I'm going to turn it over to Crystal to talk about another initiative we did called Blue Button.

Crystal: Great. Thanks, David. For those of you who aren't familiar with the healthcare industry, the Blue Button initiative was first introduced around 2010. It was first introduced actually at the Department of Veterans Affairs. The idea was you could go to a website, maybe like this. There would be a big Blue Button. You could click on it and download your healthcare records. What we realized pretty soon after that, was it wasn't enough to just give people the data, the raw data itself. You really had to give people the insights that they could get from that data in order to make better decisions about their health. That's where the vision for the next version of Blue Button really came to be.

A couple months ago, our team started working with CMS on the Blue Button 2.0 launch, which was essentially turning that Blue Button data into an API. So we took all the Patient Claims Data from locked up in PDFs or text cells or Excel spreadsheets, and we made it available through an API so that this data could be available to patients, to providers, to different actors in the healthcare system so that it could be fully integrated into health technology solutions that already existed in the marketplace.

Some examples of what you can do with the Blue Button API include if you're a pharmacy, you could use the data from the Blue Button API to better understand how a patient might improve over time if they were to adhere to the medication that they're supposed to use. If you were a research institution, you could better understand the patient life cycle and automatically update their medication information as you're preparing a clinical trial. And then if you're a provider or a physician, you'd be able to better understand all the different things that a patient experiences outside of the room that you're meeting with them in. Because these days patients are going to specialists, they're going to behavioral health specialists and there might be a picture of all the different services or drugs that your patients might be accessing that they might forget to tell you about as a provider. This helps you get a very wholistic picture of what your patient is using and what they're doing.

One example of one of our partners is Google Life Sciences and they're using data from the Blue Button API to better understand patients and better understand ... be able to merge that data with other data they have on patients and get a better picture of a longitudinal study of some of these patients over time. We launched the Blue Button API in April of this year. At the time of launch we had about 100 organizations that were set up with a developer account. Since then, we've grown that number to over 300. We're really hoping that as different healthcare technology start-ups emerge, as even some of the larger technology ... sorry, healthcare organizations embrace technology, they're able to better use some of this data on the Medicare population in order to deliver those insights to beneficiaries and then also to providers so that these patients can get better care.

Now I'll turn it over to David who will tell you a little bit more about some resources that USDS has in case you want to bring some of these practices to your own organizations.

David: Thank you, Crystal. So yeah, so what if you want to do this yourself. What if you want to do this in your organization? We have a few resources that USDS has developed that generally help improve development of APIs, development using modern software practices in general at large organizations, especially in government organizations since that's our particular specialty. The first of these is known as the Digital Services Playbook available at playbook.cio.gov, and this is a set of plays which are essentially actions you can take and ways that you can evaluate those are working that will help your organization build better software, especially for large organizations or organizations that have been having trouble building software that really suits the needs of their users, to really build what it is that your users or your customers are looking for. That's widely applicable. Very much encourage you to take a look at it.

The second resource that we have is going to be more specific to people in a government space, doesn't have to be federal, also state and local, but if you've ever had to run contracts in order to get people to essentially come in and build the stuff for you, which is pretty common in the government space, it's actually pretty difficult to write and set up that contract in the right way such that you incentivize people to do that. That's what the Agile Procurement guidelines at techfarhub.cio.gov is for. If you have no idea what that second thing is for, you're probably better off for it. But if you do know what government procurement is, then check that out. You can also learn more about both of these and more at USDS.gov.

The last resource that we want to bring to your attention is, if you're interested in doing the kinds of work that we talked about today, there's incredible opportunity in the government to have huge impact with technology skills and we are always hiring new people to help bring that expertise into government to improve the services that we give to the American people. Please apply. We're hiring engineers, designers, product managers, strategy and operation specialists, recruiters and other talent specialists. We don't just work on healthcare, so we talked about healthcare with you today but we also work on immigration. We work on helping small businesses, helping veterans, helping enlisted military members, services that touch all of these and more. We're constantly looking for new ways to help the American people. If that sounds like something you're interested in working on, please check us out at USDS.gov/join.

So that's all we have for you today. Thank you very much for your time.

Minusha: Up next, we have Palminder Singh and Shaivya Mahajan from Quotient Technology, who will share how they leveraged an API infrastructure, built an API security model, and designed an OL2.0 implementation to facilitate the customer experience for their portfolio of products. They have quite an exciting architecture that supports both internal and external tenants that federate. Palminder and Shaivya.

Palminder Singh: Thank you, Manisha. Hi guys. So it's just us two between you and lunch, so we'll try to make it interesting or quick. How many of you know Quotient? Alright. Parker and us two. How about coupons or coupons app? Same three people. Alright. So, my name is Palminder Singh. I'm responsible for the business products at Quotient Technology Inc. I'm here with...

Shaivya: Shaivya.

Palminder Singh: He was the Lead Engineer. I would say more than Lead Engineer. He was the architect behind what we're going to talk about, how we implemented all of our business products. So, every year Quotient helps millions of shoppers save money on groceries and household items. We're able to do that because we can work with every single retailer in the United States, as well as consumer packaged goods companies. We call it CPGs, such as Proctor and Gamble, Nestle, Pepsi Co., General Mills, just to name a few. We do that by providing the right coupon on the ad message to the right shopper at the right time because we have the intact data and the purchase data like no one else has. This started almost 20 years ago where we wanted to replace kind of cutting those coupons from the Sunday newspaper and be able to just print it out. We called it digital print coupons. We evolved from that time. Fast forward to about three years ago, 2015, we decided to change our name from Coupons.com to Quotient Technology for the reasons that I'm going to talk about right now.

Quick time hop, so in 2010 or 2011, we invested heavily in a product called Retailer IQ. What we did was we kind of integrated with the point of sales system of every retailer that we work with, and we wanted to deliver coupons directly to the users, not having to print anymore. So, we just power the retailers and their savings programs so users can come in and load a coupon or a cash back directly to their cards which are powered by them. Then we started moving into what we started calling this product as digital paperless. There was a shift from digital print to paperless. If you see, if you're familiar with the flyers coming out and you have circulars in a lot of those retailers that send out, it has a temporary price reduction and then at the bottom there's the coupons, so about six, seven pages or so. So we started doing that digitally as well.

We also did email marketing for our retailers. We started doing ... because we have all that data, we were able to build reports and analytics and the insights for them to understand how their brands or categories are performing. How their campaigns are performing. We also were able to do targeting and personalization because we have all that data. You see we're becoming a data company. We already have become a data company. We were a marketing company. We were a media company. So obviously, simply put we were a technology company, hence the name change to Quotient Technology. For our customers, as I talked about, we have CPGs and we have retailers, but our most important one is our consumers, our shoppers, it's millions of them. So what we do, we come in the middle is we kind of help balance the scale between retailers and CPGs which is more like the demand and supply, so we make sure there's no lack or abundance of one or the another, just to make sure that our shoppers don't have frustrating experience and they can get what they want when they want.

I'm going to talk with you about our numbers. These are all for 2017. We had 60 million shoppers, which is about roughly half of the U.S. household in 2017 which was 126 million, that are registered for the digital savings program that we power. We delivered about three and a half billion transactions. By transaction I mean when you select a coupon, that is counted as a transaction. So it was three and a half billion over the course of 2017 just in Q1 we had one billion transaction, one billion transaction in a quarter. For you, if you're a numbers person, it is 11 million in a day, it's about half a million in an hour, and seven thousand in a minute. That's how much couponing is happening. We have a stores reach of about 65 thousand and with all those transactions and coupons we were able to deliver about five and a half billion of savings in 2017.

Now how do we do all of that for our customers, which is the retailers and the CPGs? We have a suite of business products. So now we're going to start to get into how we use our kind of these business products. This is the experience that we rolled out recently in April. This isn't how it used to look before. We have campaigns, which is what our clients use for the offer management, campaign management, the entire life cycle. We have analytics which is our very rich insights and analytics platform also announced and released in April and we have shopper support which kind of helps our CS reps and the retailers who help with the consumers with their issues or their trouble-shooting. They were all Siloed applications. We had trouble with single sign-on. There were customers who were using multiple products with us and they would have to log in differently. Then we also had MFA issues because they were not all consistent and we did not have that kind of seamless delightful experience for our customers, especially business customers and a lot of them just wanted white glove service. So, we could not self-serve them onto our platform.

So of course there was a need for a strong and reliable IAM solution for us, Identity and Access Management. We didn't just go ahead and pick Okta, we actually had, go through a lot of criteria. So this'll quickly give a snapshot, it's hard to read, but basically we went through technical, feature-level functional requirements as well as pricing requirements for us. I know it's hard to read but it was evaluating few of our solutions and we ended up at Okta even though we already had Oka for ITC solution. We weren't sure at first, but then we know that after talking to Okta there was a solution we could come up with. So now, Shaivya is going to walk us through the details of how we did it.

Shaivya: Thanks Palminder. So, as Palminder mentioned we went through a lot of different criteria before we picked a solution that we wanted to go with. And as he also mentioned, we already had some products, some business products that we were leveraging both internally for our Quotient employees that manage our offers campaigns as Palminder mentioned and we also had partners that were logging into those systems, using our legacy authentication systems. So the first thing we looked at is what are the problems that we have today. Most of them were related to technical-

Shaivya: What are the problems that we have today? Most of them were related to technical challenges for what we want to do in the future, versus what we are capable of doing with our legacy system, then also licensing cost. So, previously, we were actually using a platform that wasn't really more of an identity management, it was more of a data and kind of a services platform. We were just using the OAuth capabilities of that platform to leverage basic, or to create a authentication system, just a custom solution.

So, those are the kind of two biggest challenges we saw, and what we value did our criteria on. But we also kind of wanted to look forward in the future, and see what we wanted to be able to do. This is where identity provider integrations were a big thing, because we have a lot of partners, and we want to make sure that in the future we are able to seamlessly integrate with all of them. Also lastly we want to kind of think forward for our products as well. We wanted to make sure the solution we chose also has a rich economy of APIs, and tools that we could use to kind of solve, come up with some creative solutions. So, those are the biggest needs that we had for identity management solutions. and we ended up going with Okta, because it provided all these kind of needs that we had. They were a developer friendly APIs, flexible options for creating an SSO solution for all our business products. Then also one new thing for us is security policies. We were going through kind of a change within Quotient about making sure that we meet very high standards for security and compliance, especially when handling data from consumers, and also retailers, and CPGs that are our partners. So, we wanted to make sure that we could meet those requirements with the solution we picked.

So, kind of the first thing that we looked at when designing the solution was SSO, as mentioned we have three different products that we wanted to bring into this suite of business apps. The first thing we wanted to look at is how do we create an SSO solution where a user logs into one application, and they're able to access all there data across our entire suite of products. So, the challenges that we faced, the biggest one was, like I mentioned, we have both internal, and external users. So, we wanted to make sure that they have a seamless experience whether they're a Quotient employee or a Quotient partner, when they're logging into these applications using our SSO. We want to make sure it's the same experience everybody gets, it's a customer focused, and it's designed focused. So, those are kind of the things that we, like I said these are our first priorities, and obviously we wanted to make sure security preferences, security compliance, different levels of controls were all possible with the solution that we designed.

So, this is a kind of a rough chart of what we came up with. So, you can see two types of users. We have the green which is a business user, that's our partners, and we have the user in black on the bottom, which is our internal user. Our IT department was actually already on Okta. So, they were already leveraging Okta for just our internal authentication to different applications, you know, like Workday, Zoom., all those things. Even then we still evaluated other solutions before we made the decision to just go ahead, and host our business authentication also on the Okta platform. The reason we went with that solution is because, there was really good support for Federation between the two environments. That meant that we could completely isolate our business customers from our internal users, which usually have very high levels of security that we want to meet. Whereas for business customers we can definitely relax the requirements a little bit.

The nice feature, the biggest kind of benefit to us with Okta, and one of the deciding factors why we went with Okta, was the sign in widget, and we were initially evaluating the capabilities of being able to integrate something out of the box. What do we get out of the box with minimal developer effort. That was the one thing., the sign in widget being capable of powering an identity management solution, integrating with different APIs, different application just out of the box, and being able to support end different identity providers the future was also a huge benefit, because we wanted to make sure that we can power our SSO with any number of partners, and their identity solutions in the future.

So, this is kind of the work flow of a log in to Quotient today. So, we start at the top left here, where we have a very custom looking sign in cart. So, this actually being built on top of the sign in widget. If you watch the keynote you would have noticed that there's the thing about using Okta branding. So by default the sign in widget comes with Okta branding and it looks pretty good by itself, but obviously we're using is this against our partners, and want to make sure that we go with a Quotient branded product, and give them a very seamless solution compared to other Quotient apps. So, we basically themed the Quotient or the Okta sign in widget, we gave it our own look and feel. You can really see that it's difficult to tell what is what.

So, first thing they enter is just their email ID, this a way for us to determine which org they're trying to log in to. So when a user enters their log in, we determine whether they're an internal user, or whether they're a partner, which partner they are. This helps us determine which authentication, or identity provider to authenticate them against, to send their credentials to. So, from there we go to a log in screen, and this is where the widget is really doing the meat of the work. So, it accepts the users password, sends that password to the configured org within Okta. So, that can be for us, the business org or the internal org. Once that authentication is complete, the credential authentication is complete, there's also a multi factor authentication. So, the widget also handles this. The user can configure any number of multi factor options, they can use Google authenticator, Okta Verify, SMS, which I really prefer. The widget is able kind of handle all those registration processes. The challenge for MFA, making sure the user is able to kind of, gets prompted for MFA, and also is able to answer the challenge. Once they're done with the challenge, then we take them immediately to our log in securely our homepage where we display a suite of apps that we have available. So all of this is kind of happening just using this log in cart that's built on top the Okta sign in widget, with just some basic theme customizations that we have to build in.

So, this kind of goes deeper into the Quotient platforms, and talks a little bit more of how we leverage Okta to power our APIs. So, we have a lot of different platform APIs that live behind our kind of front in. The primary, the technology we chose, and was kind of again out of the box with Okta, was JWT tokens. So, we decided to go with JWTs, because it provides portable identities. That was something that we were actually exploring even before we started evaluating identity solutions, mainly because we have a lot of different APIs. They all kind of use their own authentication access tokens, all those kind of things. We wanted to kind of make one portable solution that would be able to power all this APIs.

We went with JWTTs, that was kind of our chosen solution, and we were very happy that came out of the box with Okta. This is done using what Okta calls the Open ID App providers. So, we create an Open ID app within Okta, which is our Quotient business SSO. When a user authenticates against Okta, using either our internal work, or external work, eventually they're basically getting authenticated to our SSO application, which generates JWT tokens. So, that token contains their identity coming from Okta. So, it provides us basic claims, basic profile information for that user. Then we use that to authenticate the user to all our APIs. So once the user is authenticated for our front end, using the sign in widget, we're actually able to authenticated that use across all our APIs, make sure that the APIs understand who the user is, and are able to enforce the permissions, and access controls that we have for users within our platforms.

So, all this obviously doesn't really mean much, unless we can verify that authentication across all APIs. So the JWT token itself is actually a plain text token, you can easily decrypt it in any browser, and it basically gives a list of the claim that the user claims to have, but you have to verify those claims, you can't just accept them because otherwise I could say, you know I'm home and access all his data. So, obviously we don't want somebody to be able to do that.

The way we verify those tokens is using the JWT verification libraries that Okta provides. So, this is again another out of the box, it’s kind of like a broken record, but another out of the box solution. We leverage some of the libraries that Okta provides, with just like five or ten lines of code. We're able to authenticate at each point in our application. So, whether it's the platform, whether it's the front end, whether it’s even kind of all the way down in the DLL layer, we can authenticate directly against Okta using the Okta libraries, whether or not somebody's JWT is valid. It's doing basically a simple signature check that goes directly against the Okta environment, and make sure that the signature within the JWT token is valid. So, once that validation is complete only then are we able to expose data to our user. Lastly, I just want to talk a little bit about JWTs. So, with JWT base Auth, not only are you able to kind of drive different APIs, you can actually drive UI components. This was a big help that we kind of didn't foresee, but we were happy to have. So, we have this concept of an app launcher. So within all our apps we have a little drop down that allows a user to see a specific list of applications that they have access to. Obviously we want to hide applications that the user doesn't have access to, especially on the application launcher, because if you don't have access to it they won't be able to launch that application.

So, using the JWT we actually provide a list of the applications the user has access to within our SSO ecosystem. We do this by just using a custom attribute within Okta. So, you can assign custom attributes to somebody's identity within Okta, and those custom attributes will come through in your JWT token, and that can be decoded at any point within your front end or your platform. You can validate what the user has access to, what applications they have access to, and whether or not you should show them a specific application within the application launcher. That's it.

Speaker 1: I think we have time for a Q and A. So we're going to let David and Crystal again and have a joint Q and A.

Speaker 2: Yeah, so guys, I'm afraid we are out of time for Q and A. They shared such great information. I would say maybe they could find you over lunch. I know we're having birds of a feather conversations at lunch next. If you could please take one second to fill out the card that's on your chair, hand it so someone at the back of the room as you leave, but if we could just give a warm thanks to our speakers please.