 You switch to the camera. Hey, now we can see you before you weren't sharing your camera So I think that was the trick. I was sharing my camera But I have my camera control panel open because Skype likes to take control my camera and change my field of view So I think it was walking sky from actually attaching my camera. Got it Yeah, so let me just double-check and make sure that my field of view is set up Yeah, no problem, and it is. Yeah, looks good. You guys We can hear you just just fine. You look great. The camera looks great I'm I said we're having issues over here, and I know we got the echo so we're gonna finish it up So Bobby let's talk about Identity 100 take it away. Sure. You're screen. I am looking for the screen share Where is it? It is the button that does not look like a screen share It is right next to the little heart and be right chat There it is. Okay, and I'd like to share that screen Okay, hopefully Everybody can see what I'm seeing right now so This talk is a one-on-one introduction to identity The intention here is to learn some of the basic concepts and jargon in the space It'll be very conceptual, but in the end I hope you'll have a good understanding of why things exist and what problems they're intended to solve So Hello, everyone. I'm Bobby Johnson a developer advocate engineer at off zero I hail from the damp city of Olympia, Washington Which is known for the riot girl punk sound of bands like bikini kill and sleeter Kenny Just a little bit about me. I'm a developer advocate engineer at identity and access management company called off zero I run the Seattle identity and security meetup as well as the off-zero online meetups Both of which you can find on meetup.com I'll be hosting online meetups every week in October for security awareness month So if you're into online events, you might dig those as well I'm an avid twitch streamer and a member of Jeff fritz's live coders team So you can find me there I've been a software developer for about 20 years focused mainly on web development but I've also done a little bit of mobile development as well and This is me and my dog Louie and I hanging out in the beautiful Pacific Northwest and the Chinook pass and the northern Cascades mountain range At the bottom of my slides. You'll notice a bitly link That will take you to a place where you can find my slides Including all the notes for me giving this presentation. So don't feel you have to take screenshots of anything You'll have my slide deck available to you So while back I asked on Twitter What are common reasons to roll your own authentication and I got several good reasons? Of course all of them are wrong And let's talk about the problem that we're trying to solve when we talk about identity The idea is that you have a resource somewhere and that resource could be a capability like executing a specific process It could be a bit of sensitive data Or pretty much anything else that you can think of when you're using an application And you have a user somewhere that would like to access this resource in a secure way meaning it only allows proper usage of that resource There are not only authentication aspects of these of this transaction, but also authorization as well The problem is deceivingly simple You have a user who wants to access a resource if you look at the diagram on the screen right now It looks pretty easy, right? There are several things to consider though that raise the complexity level pretty quickly Firstly the problem space we're talking about is extremely critical if something goes wrong. It goes catastrophically wrong Think like 11.4 million euros level of catastrophe in the event of a breach This fact alone makes it one that requires a lot of attention Next the resources are complex and so are consuming those resources We exist in a world where everything is programmable Everything has an API exposed and those resources can be accessed by a large variety of devices Not only your computer, but your phone your watch your thermostat I recently went to home depot to buy a new refrigerator and they had several models with the ability to tweet I have no idea why I'd want to tweet from my fridge, but I immediately find the security of such devices suspect Finally the accounts we use to access all of these resources existed in an incredibly wide variety of sources Users can come from businesses through enterprise directories or users can come from social networks I imagine everyone that's watching right now has at least a Facebook or Twitter or LinkedIn account Users can come from entirely custom solutions where an independent software vendor or startup decides to put all of their users in their own database And wrap them in their own rules Now consider the Cartesian product of all the possible devices resources and users and you can see why the problem can become complex very quickly Also consider that developers implementing these things in an organization are not typically experts in the identity space And they have little desire to become an expert in identity and security They're mainly focused on shipping product and solving problems for their end users Identity is an infrastructure concern at best to them So let's take a historical tour and see how the industry evolved the various standards from the simplest to the most modern protocols that are in use today So here I have a user and a web application Think about the application and what it's trying to achieve Is it Amazon and I'm trying to buy something Is it an expense system or I'm trying to track expenditures to get reimbursed Or is it a tax system and I'm trying to file my taxes All of these applications perform a business function of some type and for each of those functions there'll be a different set of attributes which define me as a user that's relevant to that application For example, Amazon will want to know my credit card number and physical address so they can charge me and send me stuff And a tax system will want to know my yearly income and maybe my tax identification number These attributes still represent me I am the person I am the same person but depending on the application I am working with my attributes or digital identity will be different Let's say that yesterday I connected to this application for the first time and entered my digital identity into the system Then today I come back to the application How does that application know it should use my digital identity Versus one of the other people that use that particular website I must provide credentials in the form of a username and password Between the application and myself is an agreement to a shared secret Something that only I and the application know I'll provide this secret to the application to reassure it that I'm the same person who shut up yesterday So retrieve my digital identity that belongs to me and use it in the scope of the business process that the application provides So even though this is a primitive approach, username and passwords are still in use every day today Which is one of the interesting aspects of identity There isn't a strict replacement of old methods when a new one comes along Typically new techniques come along to address new scenarios that weren't possible before And it evolves to increased complexity However the old protocols and approaches, if they still work and there's no direct competitor Then there's still be in use The next evolutionary step that was intended to solve a very specific problem Think for a second about what happens within a business Within the boundaries of a company or enterprise, you can expect a user to use multiple applications If we use the same username and password approaches before We'll end up with every user having their credentials stored in every application The user must authenticate with every application they wish to use Requiring them to remember passwords for each application Or worse, using a single password for them Ensuring they are compromised in multiple places if that password leaks In general, having multiple apps deal with attributes collection and credential management Separately is a colossal waste of resources for everyone For the developer, they need to duplicate the same functionality in every application And keep that up to date For the user, they need to deal with provisioning all of these accounts and managing passwords But above all and very important for our business Our administrators need to chase every application and make sure every user is configured correctly The username and password approach doesn't scale in that scenario In my example here, I only have four applications, but your typical enterprise could have hundreds of applications It's just not going to work So the industry reacted to this by creating what is known as a directory This is a .NET conference, so we're all probably familiar with Active Directory A directory is a centralized repository that performs the credentials management and digital identity storage that I talked about earlier Directories centralize this functionality in one place, and everyone's happier The user only needs to authenticate once with one central entity And then they will be signed in automatically to all the applications they require to perform their job Which is very convenient for them The applications don't need to deal with authentication directly, so there's a time and cost savings there There's also a security benefit as well A centralized directory offers a smaller security surface Finally, administrators have one central place to provision a user or update when a user leaves the company Causing that user to gain or lose access to all the applications at once Within the boundaries of an enterprise, directories solve a critical problem However, this is far from being the end Consider one of the most straightforward business scenarios, a retailer A retailer has all of its own internal flows and user management requirements But the business goes beyond the boundaries of that enterprise A retailer has suppliers, people managing their warehouses Corporate customers with whom they have an organization-to-organization relationship Which is different from an individual customer Internal directory-based single sign-on and authentication within the boundaries of an enterprise No longer work when you have more than one company that need to collaborate over the public internet In particular, think of this scenario here Imagine there's a web application in the domain on the right that a user from the domain on the left needs to access The domain controller on the right only knows about the users within the boundaries of the company on the right The user from the other company doesn't exist in that directory So what do we do now? The industry addressed this by raising the level of abstraction in the world of protocols Kerberos and the protocols that work within the boundaries of an enterprise operate at the network level To operate at the network level, the solution needs to be within a well-known boundary And even possibly requiring a certain type of network hardware All of which is not possible when you want to collaborate across the public internet People at the time looked at the roles, messages and primitives defined at the network level And created a representation of those things at the higher application level These protocols were named SAML or Security Assertion Markup Language SAML is a protocol that describes the roles the entities can play in the context of identity transactions SAML defines messages exchanged across the different entities, specifying high level transactions Used for connecting the separate entities without knowing implementation details Raising the level of abstraction to the application level removes the need to rely on special network hardware So can work over the public internet How does SAML work though? Imagine sitting in front of the web application on the right is some software The specific kind of software doesn't really matter But it's typically implemented in such a way that it can intercept and act on a request Without the application's direct knowledge In this example, in the example of two companies collaborating The one on the right must configure their system to have a trust relationship with the one on the left Trust means the application for the company on the right will believe anything the identity provider belonging to the company on the left says about users If the identity provider on the left says that the user is valid and authenticated correctly The application on the right will trust that assertion When the user in the domain on the left requests access to the application on the domain on the right The SAML implementation will intercept that request and determine if the user is unauthenticated The SAML implementation then crafts a sign-in message using a well-known format And redirects the browser of the user to the trusted identity provider in their own domain That provider is some local resource to the user from the company on the left In most cases, the user is already authenticated with that identity provider Because it's within the boundary of the company on the left's enterprise This is a good demonstration of how the various protocols layer on top of each other to provide additional functionality The company on the left could be an entirely Microsoft shop using Active Directory to provide directory services to the company And the company on the right could be using a completely different directory service The SAML implementation sitting on top of both of them provides the seamless integration point translating between the two boundaries Once the user successfully authenticates the identity provider on the left issues an entity called a security token A security token is just a bunch of bits that represents the proof that the user has successfully authenticated with the trusted identity provider A SAML-based security token consists of an XML payload and a digital signature The digital signature provides confidence that the content of the XML payload is truly coming from the trusted identity provider This concept is key to maintaining trust The company on the right can say they trust what the identity provider on the left says about users But there must be a way to verify the message is actually coming from the identity provider on the left The signature actually needs to is there to do that role So I can hear you guys in the control room Not sure if it's coming through on my mic though So another aspect of the SAML security token is that it can contain user specific attributes that describe the user in question Which allows the application consuming the token to have no need to cache those attributes It can actually receive the attributes as they are imported It can receive the attributes that are important for the function it provides directly from the token That information is simply supplied on the fly An attribute that travels inside a security token describing a user is called a claim A claim is an attribute combined with a signature asserting the attribute came from a specific source So to make this more clear, consider the difference between me putting my name on a post-it note And trying to enter Canada versus pulling out my passport that shows my name The medium here makes all the difference The passport is allegedly difficult to counterfeit Whoever receives it can validate it's a good passport and can have the trust that the US government says my full name is Robert Presley Johnson The post-it note on the other hand has no credibility whatsoever It could have come from anywhere and I may or may not have even written it myself Claims in a security token can be trusted because we trust the issuer of the token And can validate that that token came from that issuer So so far we've been exploring years of the history of identity in the world of business Meanwhile the consumer world was pretty much at a standstill Each public-facing website allowed consumers to log in with a username and password to access their services But a problem arose when these services began attempting to access other publicly available services on the user's behalf So consider the following scenario Say I'm a generic internet user using both LinkedIn and Gmail LinkedIn decides that it would like to take advantage of the fact that I already have contacts in Gmail to send LinkedIn invitations to my friends and acquaintances For example, assume that Gmail has its API that they use in their applications to send emails, list contacts, and similar email type things LinkedIn just wants to take advantage of that API A common pattern that exists today to solve this problem is for LinkedIn to request my Gmail credentials Gmail has a database containing my username and password credentials and user attributes similar to what I've described before LinkedIn simply asks for those credentials which it stores and uses to access my Gmail contacts and send invites on my behalf Giving Gmail your Gmail and username and password to LinkedIn presents a significant problem though It might be legitimate for both LinkedIn and Gmail and me to want to do this feature that I want to do, especially if I want to expand my LinkedIn network It's to the advantage of all parties involved to automate that process, but the implementation in this case is kind of terrible I must now rely on LinkedIn to protect my Gmail credentials LinkedIn might not be as committed to that protection as Gmail because they don't own them, Gmail does What happens if LinkedIn doesn't adequately secure the connection between my browser and their site when they're asking me for my Gmail credentials? It might be possible for someone on the Wi-Fi network at Starbucks to intercept those credentials and then have access to my Gmail account Of course, Gmail would never make that mistake because their business depends on the security of my Gmail credentials But LinkedIn, on the other hand, maybe not They're asking for the credentials for a one-off little feature of their application It's not as critical to LinkedIn as it is to Gmail There's an even more subtle problem here though With the Gmail username and password, LinkedIn now has full access to everything in my Gmail account Not only can they harvest my contacts, but they can also read my emails, send emails on my behalf, delete things, including the account So they can do whatever they like, which is crazy of course Why would LinkedIn want to do that? I'm just saying the possibility is there In general, people should never give credentials to any place other than the origin of those credentials The industry introduced OAuth as an open standard to address precisely this problem that I've just described OAuth is a delegated authorization protocol It allows a user to delegate authorization to one resource to act on another resource without exposing the user's credentials OAuth is a standard that defines two endpoints, which resources such as Gmail and LinkedIn can expose for helping people do delegated authorization flows Let's go back to the scenario Following OAuth, LinkedIn directs my browser to what is called an authorization server hosted by Gmail An authorization server is just a collection of two endpoints defined by OAuth An authorization endpoint, which serves up UI, and a token endpoint, which deals with API access Gmail's authorization server receives the redirected request from LinkedIn This request is formatted to say something like Dear Gmail, I'm LinkedIn You know me because I'm registered with you, and I'm a known client I have a user, I would like you to grant access to their contacts and the ability to send emails on this user's behalf At this point, my browser is pointed at Gmail Gmail will authenticate my session if I'm not currently logged in This authentication is happening in the proper way, I'm sending my Gmail credentials to Gmail Once Gmail has validated my credentials, it examines the incoming request and prompts me saying Dear user, here's LinkedIn They would like to access your contacts and to send emails on your behalf Are you okay with that? I as a user am given a chance to give my consent that I'm okay with LinkedIn having this specific access to my Gmail account Once granted, Gmail's authorization server will generate an authorization code and redirect my browser back to LinkedIn with it So far this handshake has performed directly in my browser over the public internet Once my browser is redirected back to LinkedIn with the authorization code, LinkedIn will continue the flow server side LinkedIn will take the authorization code along with its set of client credentials and call Gmail's authorization server's token endpoint This message is saying Dear Gmail, I'm LinkedIn, here's proof I have a code that proves this user gave consent for me to access your API on their behalf Gmail's authorization server will first evaluate the client credentials and then the authorization code If everything checks out, it'll generate an opaque access token I as a user consented to giving access and this token proves that as well as the permissions granted These permissions are typically expressed in the context of OAuth as scopes I say this is an opaque token because it contains no valuable information for LinkedIn The token only has meaning to Gmail, the issuer of the token The OAuth specification has no advice on the format for tokens as long as it's capable of conveying meaning to Gmail, the issuer of the token This is how the industry solved the delegation problem and OAuth 2 is a very popular protocol today Of course, things didn't end there Quickly people started to use OAuth not for delegation but as an authentication mechanism Consider our final scenario Imagine that LinkedIn does not want to maintain its own username and password store They would have no way of signing in to LinkedIn directly LinkedIn could do the same OAuth dance that I just subscribed earlier to gain delegated access to Gmail's API with an anonymous user As soon as the OAuth flow is completed successfully, LinkedIn could assume that since the user has proven they are a valid Gmail user They are considered authenticated by LinkedIn as well Drop a session cookie and continue on But remember with OAuth the access token is opaque The token issued by Gmail has no meaning to LinkedIn If someone manages to make an attack and the access token that I get from Gmail happens to belong to another user LinkedIn has no way of telling LinkedIn will be given the illusion of being authenticated when in reality the token belongs to someone else completely This is a fairly well-known attack called the confused deputy attack The industry took OAuth and added some details on top of it known as OpenID Connect to solve exactly the problem that I just described OpenID Connect takes OAuth and adds primitives for correctly achieving single sign-on OIDC adds a new type of token called an ID token This token is no longer opaque, it follows a specified format, the JSON web token format, or JOT for short This token is meant to carry pretty much the same information that I described earlier with a SAML security token It carries user information and can be validated OIDC has also introduced a standard API interface to the authorization server for querying identity information called the user InfoAPI Finally, OIDC introduces a way to get ID tokens directly as a part as an authorization endpoint flow Which brings the public internet up to parity with SAML basically And now we've come to modern times OpenID Connect is widely used as an identity protocol on the internet right now And we've visited the main scenarios that prompted the evolution of protocols in the identity space Of course, this was just a taste of the world of identity and how identity has evolved from simple username and passwords all the way to OpenID Connect So if you'd like to keep up with me, you can find me in these places Once again, you can find all the presentation materials at the bit.ly link at the bottom of this slide I want to thank the organizers and all the people behind the scenes at .netcom for having me And most of all, I want to thank you for your time listening to me I hope I've armed you with a bit of context around identity Thank you To the Q&A, can you hear us okay there? Bobby And I think you guys are muted Oh, come on Yeah, the context on the window switched out So hey, can you hear us okay now Bobby? Yeah, I can hear you good Perfect. Hey, I got two questions for you over here Okay So the first question Michael Jolie was asking If you're using JWTs to authenticate requests, is it okay to store that token in local storage or a cookie while it's valid? If not, where should I hold it? Sure So your application architecture kind of dictates the answer to that question But if you are working on a system where you can store HTTP-only cookies Putting that token in there on traditional server-side rendered type web applications is totally viable You just need to be aware that you won't be able to access it client-side And if you're attempting to use that token for say Hitting an API that's not on the same domain as where that cookie was served up It's not going to work for you In your single-page applications when you receive any type of token It's generally bad form to store them in local storage Local storage is a resource that is available to all scripts running on a given page So if you happen to have a malicious script loaded via an ad network Or even maybe an MPM module that is suspect that happened to get into your single-page application They would be able to scrape your token So generally we say to avoid storing them there The best bet is to store your tokens in your actual application memory itself So like say in your React applications you're going to have an authorization module That just holds a variable reference to the token itself And then when a user circles back around and loads the page again You can reach out silently to the authorization server to retrieve those tokens You don't necessarily have to prompt the user to log in again Gotcha, that's a great answer It was more like a statement but I kind of went through and reworded it as an answer So it kind of makes sense, it's from Cobra 2 And this is my rephrasing of it Is the implicit flow of OAuth deprecated? And if so, can I... Is authorization code the replacement? Sure, so the implicit flow is what we've typically used in the past for single-page applications It is not deprecated but a new flow has come out called authorization code flow for proof key for code exchange We call it pixie for short Which brings single-page applications kind of up to parity with what mobile developers have been doing for a while So while the implicit flow there aren't necessarily any new exploits you need to be concerned about Pixie is a little bit more secure and if you're building new applications and your authorization server supports it You should probably go with pixie over implicit flow But if you have a bunch of applications currently that are using implicit flow There's no new attacks out there you need to be concerned about Perfect, sounds great I don't see any more questions And since we're kind of right at 6.59 a figure we can finish up and get the next speaker Because we have Martin here on studio Hey Martin, good luck Thank you so much for taking the time to speak with us And we all learned a lot about identity Awesome, thank you for asking me We're going to get things here shifted a bit and we'll be right back