APIs & Identity

Karl:  We're gonna talk a little bit about APIs and security.

So, what is an API? We've been talking about a lot of things today, just high level, right? So, APIs are how you expose your data to your apps. How your apps get to consume what your business is doing, differentiate experiences to your customers and increasingly, as Paul Graham quotes here on the tweet, it's increasingly self-service business dev. You can unlock a lot of innovation by opening up your APIs and your data for external innovation that you might not have the resources or prioritization to solve.

And increasingly, applications are moving from web-based applications that you've been seeing in the Chiclets in the Okta dashboards today, so stuff that we've all been deploying and managing for the last ten years, to more modern type of applications, where it was called single page application. It's sort of like the Gmail kind of app, where it's an app that doesn't actually ever refresh, it just stays running the whole time. It kind of behaves like a desktop app. And then, obviously, the rise of mobile and native mobile applications all basically built on top of APIs and consuming APIs.

And the applications are being deployed in the Cloud and the deployment models are changing. You used to just deal with maybe a weekly or monthly deployment schedules or an application upgrade window. Now, applications can be deployed in minutes. They're very dynamic. Deployed on the public internet, exposed to end users, to customers, to partners without a VPN. And that's somewhat of a scary proposition when you lose that perimeter and needing to secure the data behind these services.

The types of experiences we want to deliver are being connected across the different devices contexts. We have Alexas, we have iPhones, we have iPads, we have desktops. Increasingly, it's a question of how can I deliver a compelling experience across all the different devices, which requires an identity to be able to connect the dots.

And that leads to the rise of what's commonly called the API economy, where the business models and API product managers can find different ways to drive revenue and connect with your business partners and suppliers to deliver value-added services.

So, a lot of companies these days have API-driven initiatives, whether it's from billing these new mobile experiences that are next generation, whether it's connecting to your business partners, billing an ecosystem for developers to unlock that innovation, or just trying to centralize a bunch of shared services and trying to create an internal platform to be more agile in your organizations. I'm sure a lot of you guys have all these API-driven initiatives going on.

And so it leads to the question is how do you secure access to your APIs in this new Cloud native mobile first world?

What you don't want to do is definitely sprinkle passwords across all your applications and then give the applications and partners access to those credentials. This classically, on the consumer side was a big problem back in the last decade, where you didn't want to necessarily give an application that wants to get access to your contact book, your credentials and go out and beat you. You want to constrain what it can do and have specific permissions on what it can do.

So, if you've ever seen one of these kinds of screens on your day to day web activities, you've used something called OAuth. So, OAuth is the modern protocol stack for interacting and securing with tokens to access APIs.

So from a very high level, we have our four entities here. We have the API on the right, which is called the resource server. You have the app, which is also called the client. That's either your native app, it could be a browser, could be a TV. You have the authorization server, which is a role in OAuth that mints the tokens and then you have the end user. So the user accesses the client, obtains the token from the authorization server, and hands the token over to the resource server. So it's a token-based model with OAuth.

And as an analogy, you can kind of think of it sort of like the analogy of going into a hotel, getting your token from the authorization server, from the agent, being able to then take that token and present it to the door that it was authorized to use, that key card will only work on your door, right? So, if I have that key card, I can get access to that resource. So, that's sort of the mental model when we talk about OAuth, that you're trying to manage is the authorization server really has most of the logic and who can do what, and then the resource API just is tied to, "I am room 21, as long as the key card is 21, I'm good to go". So it kind of can separate those two concerns.

So, if we look at these different application models and see how they've been deployed, we have your traditional browser-based application, which might do a SAML flow or an OpenID Connect flow to log in to that web application. Now, that web application then in the back might have to call APIs to go get data. This could be data exposed from your data services, it could your Oracle services, it could be line of business services. That web application is gonna need to call out to those back end services, and you're gonna want to protect that probably with OAuth 2. Now, that same browser application may directly, because it's a more modern application, hit APIs directly. And so it would need the ability to use OAuth 2 to do that. That same native experience wants to use that exact same API that I already shipped for my browser apps. So, I've already gone through the work of exposing these core services, and now I wanna bring a new client on board and I want to be able to give it access. Or maybe it's a partner application sitting at another data center that wants to hit that same API that's super high value now, because now I'm servicing three different client types. And then that API also calling APIs.

You can see this sort of mesh model going forward, where APIs are calling APIs, apps are calling APIs, and OAuth 2 being the key technology to secure it.

And so when we talk about the client applications, it's everything from command line tools to internet and things, to APIs, so it's not just limited to mobile application. It's becoming this sort of defacto standard for modern authentication for APIs going forward.

And what's neat about it is that it forces a registration flow for your applications. A lot of times in the web base world where you had access management, let's say the HDP layer, you weren't really sure what these applications were. With OAuth, there's a forced registration, where the app has to basically get a license plate. And it has a registration for that, it gives you the opportunity to request work flows, be able to understand what's going on with your APIs, implement processes around that part of it. And then the client gets an actual identity that you can use for auditing and security and revocation exercises down the road. So now that applications have first class identity, it becomes a much more interesting authorization scenario.

So here, what we've seen is a classic OAuth screen, where it's asking you, "Hey, these are the permissions I want to allow. These are the permissions I'm not gonna do". We call those scopes in OAuth terminology, but they're basically the fine grained bundles of permissions, course grained bundles of permissions for the application. And we call those the scope, and because now we know which application is trying to access that API, we can restrict that app to have specific scopes, which is a very different value prop. And then we can optionally require consent, whether we want them to approve it or not. And we can revoke that access. The key takeaway here is now we've decoupled a bit of the authorization and policy and decision making from the authorization server, which is issuing those scopes to the resource server that's consuming the tokens. That really puts a different viewpoint on what you've traditionally used as your web access management policies that may have been more URL-based where you're trying to sort of reverse engineer the applications or try to come around the app after the app is already shipped. This puts it into the development process when the app is built, they have to think about these permissions. They have to register these applications.

So we get these sort of first class concepts in authorization now that we can do, which are gonna add a lot more value than just trying to look at the world through URLs.

So, there's been a lot of technologies before to manage access to APIs. There's your traditional device that's sitting on the gateway on the edge of your network. That's either filtering, proxying, a very traditional premise perimeter based model. But you have to configure these devices. And your developer are speaking code, they're doing deployments. The policy has to be in line with where your business is going and there's a friction here between the IT team that may not be fully aware of all the intricacies of the apps, and the developers trying to deploy. And the on prem access management technologies, to be able to do this, are the same problems of upgrade, patching, scaling that you have to take the ownership to do.

So we find there's an opportunity here to apply an Okta look at the problem statement and how can we integrate identity and API access into a single product. And we call that Okta API Access Management.

So Okta API Access Management at its core is an OAuth server that you get to customize for your application concerns. It's been OpenID Connect certified, you can assure interoperability with your applications. It's built on a flexible identity-driven policy engine. We talked a little bit about policy in the last presentation, we'll talk a little bit more about how that's applied to API resources. And a very easy centralized viewpoint of how the APIs are being accessed in your environment.

The flexible identity-driven policy engine is built on top of our universal directory product. So, whether you're connecting active directory principles, LDAP, external identities being provisioned inside of Okta, being able to have that centralized view to be able to say these groups from these IP ranges accessing these particular applications, get these attributes and these scopes. And so that gives you a pretty powerful vocabulary to build your course grain authorization roles.

And that's in contrast to having to manage this across XML files or other policies layers that you may have traditionally used in the gateway days of having to do web server security.

The interesting thing when you tie identity and API access management is that you're able to govern the life cycle of the tokens and access based on identity events that have happened.

So, in a traditional flow here, the user is gonna sign into the application, the application is gonna make a call out to the OAuth server to get its tokens and get authorized, comes back and gets signed in to the application. The application then goes and hits a bunch of different APIs to go do the activities, whether it's getting mail, getting data, submitting tickets, whatever the application needs to do to its APIs.

And then the identity life cycle matures. You have the classic joiner, mover, leaver, Okta problems that we've been talking about in our Okta lifecycle management products. A trigger happens from say work day or from active directory. Say the user was deprovisioned or he no longer is an employee. That will kill the refresh token that the application is using to hit the APIs and so the next time that application goes out to try to get a new token, these tokens are short lived, five minutes, ten minutes. It goes back to Okta to get a new one, and it says, "Sorry, I can't give you one. The user's been deprovisioned. We've now integrated the protocol layer and the application concerns with the identity life cycles so that the same thing you would expect to have happened for killing access for an employee for SAS applications could happen now to your APIs.

Managing APIs is more than just security. Your API initiatives may have additional needs. Managing reporting, billing, besides just the core security concerns. So, Okta has partnered with our product with leading API management vendors, such as MuleSoft and Apigee and Amazon Web Services to integrate our OAuth offering into these solutions so that when you have additional classic API management governance concerns and reporting concerns, you can still leverage the identity engine, identity store and access policies inside of Okta, and leverage the reporting and analytics pieces for your APIs and API management product, as well as the traditional things such as message transforms and plugins, things that you may need to do from a data perspective.

What this leaves us with is an architecture where we have multiple different points where we can think about enforcing security. So, there's the application when it gets registered, so they're known applications. There's the authorization server, it has the policy on what scopes and claims the user and the client can have. There's now this layer at the gateway where you can do course grain authorization, where I can say, "Hey, as long as you have API read permission, I'll let you do any read operation but write operation you don't have". So I can do this edge level filtering at a course grain level. And then finally, I could hit the individual APIs that know more about the types of resources that they're managing, patients, doctors, whatever the domain is. It may understand a little bit more about it and that's where you can do your traditional fine grain authorization.

In a nutshell, that is what API access management. What I wanna do is go into a demo mode and have a sample application and show you how that looks inside of Okta.

Can you switch to the laptop? Cool, awesome.

So this is the Okta dashboard. We've been looking at this all day today. I'm logged in as an administrator. I have a mobile application that was developed for a patient provider scenario. So this is an app, you could think of this as an app that you would download in the app store as a patient, I want to schedule an appointment with the doctor. So that's what this mobile app kind of need of experience would be.

I also have a web-based application that is your traditional management portal. So this is where, for example, a provider would go in and manage their appointment requests and approve them and reject them.

So we have a native mobile experience, a web experience, all powered by the same API, protected by Okta in the back end for this with a very branded custom development experience where it's not branded Okta, it's branded as your application.

So in the Okta management screen, I'm gonna go into the admin console. The first thing you're gonna wanna do is you have to register those clients I mentioned. We call that the OAuth client registration pieces of it. So the first thing I can do is I can go add application, I can say create new application, and you notice now down here, we have this option, instead of just picking SAML or the plugin base authentication, I can pick something called OpenID Connect. OpenID Connect is the single sign on authentication protocol built on top of OAuth, the more modern SAML that's built on OAuth for new use cases. So here, we let you pick that as a sign in type to use as their OAuth application.

I can pick a native application as an example as well. So we've templated this by your use case. As I've mentioned, that's single page app experience, a native experience, or a traditional web server. There's a lot of technical details at the OAuth layer and why I might want to do those different flows, but that's what it's trying to ask me there when I pick it. I actually wanted to pick native. Cool. Native app. Awesome. So I'm gonna register a native app. My native app. Traditional Okta experience here. This basically just tells you does the tokens get redirected? This is an app specific setting, so the developer has chosen where the app gets set. So I go to Okta, Okta, tokens, that's where I want the tokens to be redirected on my app. And then I have an OAuth client. So, I've mentioned that driver's license plate, the driver's plate, it's basically my client identifier. So I would use that and embed that into my source code for my application to say I am that application.

And here is the application credentials for managing that application. And I would assign this to users just like I would any other app at Okta. So it's following the same paradigms of any application. So I can say assign to groups. I have, for example here, an Acme Health patients and providers group. So if this is the native app, I want patients to be able to access the native app. So I'm gonna assign my patients.

Back on the sign on tab, we mentioned in the previous talk about our rich app level MFA capabilities. I can still leverage these here as well. So if you happen to have an application that needs higher assurance requirements, you can go down here, specify your MFA requirements just like any other application, and when they do the log in flow, they'll get prompted for MFA. So we're built on the same infrastructure here for our OAuth. 

So that gives me a base application. I can then use those credentials into my application. But now I need to set up one of those authorization servers that gives me access to an API. So we're gonna go to the security tab, hit API, and here you see the dashboard for creating and managing OAuth authorization servers. So this is effectively OAuth as a service. I get to just with a single click of a button, set up an OAuth server. Don't need to deploy anything, don't need to provision or procure new hardware or a new service. I just get to just come in here and say my authorization server. And then this authorization server is gonna manage, for example, tokens to API acmehealth.com. So that's where its security domain for tokens is.

You can carve out multiple of these inside your networks. Reason may be you have a dev and test cycle and you want to maybe deploy to a different Cloud or different technology and you don't want security tokens for your dev or your test environments you use in your production environments. This is up to your application developers and your IT governance policies on how you might want to segment your different security domains. But here, I'm just gonna create one simple one. And I have an authorization server up and ready to go. And this authorization server speaks all the standard OAuth protocol stuff.

Just to show you that it does work, I'm gonna go fetch a piece of metadata right now from the authorization server telling me all the OAuth capabilities that it supports. These are all standard RFC protocol stuff. So right now I have an authorization server, but it doesn't know what permissions I can grant.

So I have to go to the scopes tab and be able to start assigning the types of permissions. And this is an opportunity for you guys to have a conversation with your application developers on what are these permissions that your applications need, where are the angularities that are supported, how can I map those to my enterprise roles and groups that I may already have, or my developer personas? And so an application in this example, is we might have a permission called Appointments.read. Or colon read. So this is a read permission to view scheduled appointments, and that was something the application developer and the API developer agreed on, that my API is an Appointments API to schedule appointments. There's a read scope that you can ask for. So now we put that as a contract here on the authorization server.

I can then go to claims. Claims are much more like SAML attributes. You can put claims inside of tokens. There's two tokens, there's a single sign on token and there's a token to access the API. You can pick which scenario you want. So if I had, for example, a claim such as patient ID, I could do that and I could go using our Okta expression language on top of our universal directory, you'd be able to pull custom claims out of any attribute that you pulled inside of Okta. So there, the power of universal directory is now just showing from single sign on and identity life cycle to now flowing into any API. So a common use case would be I want to have a department or I want groups from active directory to flow inside those tokens. Here's where you're gonna configure which attributes would flow to that.

And then the last piece is tying it all together, is the access policy. So I'm gonna create an access policy, My Resource Policy. And the first thing it's trying to say is does this policy apply to all OAuth clients or specific OAuth clients? The default obviously being all, but if I wanted to, I could say, actually the ACME Health web application applies to this policy. So this is pulling up A list of registered OAuth clients in your organization. So my native app is the one that I created. So this policy would only apply to that guy. Cool.

So now I have to add a rule. And the rule now gets into the more targeting of those scopes to what an application can do. So grant patient groups. So here I'm able to do fine grain targeting. Which OAuth flow, that's sort of advanced use case. I can drop down here and add further level group base targeting. So if I want patient or Acme patients, I could do a different rule for patients versus providers. A great use case there is obviously you're gonna have privileged account administrators, you're gonna have service applications that are running in the background, you might want to grant those guys more permissions than say the app that's in the app store. You don't need the delete all data permission. Maybe in the mobile app, and maybe that's something that you need in a backend maintenance task. Here's where you're gonna be able to carve those out. And if I grant these scopes, I go here and here is where you'd be able to say appointments read. It's one scope. And then you can change your token time outs. I mentioned there is that short lived time out, before the token expires, I have to go back to Okta to get a new token.

So there's sort of two tokens to handle that. The first one is what we call the access token. That's used to hit the API. When that guy expires, you go back to Okta with the refresh token to get a new one. So that gives you the ability to reapply all of your life cycle checks, your policy checks, to make sure the account is current, to be able to issue that next token, because it gives you that point to check in. And from a performance scalability perspective, you're not calling home with every API call, so you get the ability of saying I'm willing to allow a certain level of window for you to hit that API, decouple where you don't have to call home, but you're gonna have to call home say every five minutes, an hour, to go back to verify your account. So this is something you would toggle based on your security requirements on the type of resources that you're protecting. Maybe a more consumer experience, maybe hours, up to a day. Obviously a very privileged operation, you're gonna ration down. So I'm able to configure that.

So now I have an authorization server, I have a policy. Policies are gonna issue scopes and claims for clients. So, that effectively gives me all the components I need to create an API consumer and log in as that API consumer and get tokens and access that. So I've sort of pre-integrated two different applications for the demo because you have to compile the code with all those identifiers in it. There is the web application, which I showed you was your traditional web portal. And then there's the mobile application. And going back to my API servers, my Acme health authorization server already has an authorization policy. It says grant patient scopes. As you could imagine here, these are basically read and submit appointment, but I don't have the ability to approve appointment as a patient. Whereas a provider, a health care provider has more permissions. He can go in, for example, and confirm appointments. So he has an additional scope there.

So now let's switch over to the app to see how from an experience perspective, how that would work. So the first thing you do when you launch the app, you're gonna get the log in button, click log in. This is using best practice technologies that we've been working with the industry and Google to come up with best practices for mobile applications, where the credentials I'm typing in here, as you can see, are in an embedded view, so that the application can't grab my credentials. And sign in. Cool and no appointments available.

So now I'm into the application, I click on My User, I'm logged in. This is pulling that data from the universal directory and using open ID connect to grab that profile data using tokens. Now create a sample appointment here, let's just say for 5:00. Click demo. Request the appointment. So, pending approval. So I have an appointment scheduled and as a patient, it's in pending approval. Now again, under the covers, it's issued in the OAuth token from the OAuth authorization server. Use that token to hit the back end APIs. The back end APIs are just running as one of these embedded developer web servers here, so they can see that I've just logged in here. Created this appointment.

And so now, I'm gonna switch over to the administrative console. So this is identity protecting based on the roles and groups in Okta for me to be a patient to only be able to do patient operations, but I want to be able to approve that appointment. So now I'm gonna go to the web-based console. So in the web-based console, I'm gonna log in as a health care provider. Sign in. So my user here is health care provider, so I have this new tab that showed up. So this tab can be hidden based on my identity claims. So I can pass those claims in the tokens, say I'm a provider, and if I am a provider, like this thing up in the screen, if I'm not, hide this part of the screen. So traditional role based checks that developer would be doing. That's how the screen appears. And now if I confirm this appointment, which is a permission that's only granted to the health care provider, I come back now to my mobile application and my ... if I can do this refresh. Yep, turned green, so my appointment's been approved. So, that's showing live application between two different consumers, two different identity contexts that's happening.

So that's sort of the power of integrating Okta's identity. Universal directory, policy, MFA offering is with your API security strategy, is that you have one pain to solve the whole API scenarios that you're tying to build through these new experiences.

So, there's one other thing, it's not just web applications. I'm able to also model partner services as well. Partner services uses a particular use case of OAuth where you don't have a user identity. So, in a partner, the app is acting as itself, it's just an app calling an API, so you don't really have a user context. So you'll notice here, because I don't have a user context, I just have the general tab for this application. I could then go back to my API policy and give this guy a little more increased permissions, for example, because maybe he is gonna collect some billing data or something about that application.

So we can model pure applications calling APIs, web applications calling APIs, native applications calling APIs, cut the base at a primitive to really provide a rich layer for API security.

So that's what I wanted to show for Okta with API and security. Thank you guys very much for coming today and I'm gonna turn it back to Alyssa.

Speaker 2:  Ladies and gentlemen, please welcome back Alyssa Smrekar.

Alyssa Smrekar: Hi there everyone.