 I want to say it's nice to come into the warm, but I'm from Melbourne. It's nice to come into the cool. I was walking down the streets of Singapore today in the absolute sweltering heat and I love the fact that some stores have their doors open and let all the air-con out. I hate the fact from an environmental perspective, but you just slow down a bit, don't you? Just walk on a little bit. So I want to talk to you tonight about, it's an introductory talk about identity. So what is OpenID Connect, OAuth 2, and the things of that sort? I tend to walk around a lot, which has two implications. One, the person on the camera has to keep moving the camera, and two, I keep standing in front of the presentation that you're looking at. So I'll try not to do that too much. If I'm getting in the way of something, just stick your hand up and tell me to move. I can speak a bit louder. Do we have speakers? No? Well, yeah, but I was just wondering whether the speakers work. Do the speakers work? Yeah, he's just asking me. I have no idea. Oh, there's a little mixer here. What does that do? We have power now. Oh, you can hear me. Hooray! That's so much better. So I'll go from the beginning, not all of it. So my name is Ben Dettroy. I'm a developer evangelist for OAuth 0. Developer evangelist basically means that I evangelise developers back to the company. So I go out and I talk to people sometimes on the street when there's no venue, but usually in offices like this about anything from security, identity, privacy, those type of topics. And I love to find out how people are facing the challenges in their products and in their software development so that I can learn more about what people need. And if OAuth 0 can't solve that problem, then either get OAuth 0 to be able to solve that problem or maybe have a chat and see if there's any other ways you can address those issues. But tonight I want to talk to you about identity, not so much the security and anonymity side of things, and beyond. So an introductory talk, like I said. Clicker doesn't want to work. Oh, here's my keyboard. So, where did identity start? It's a bit of a history. I'll sit down. How's that? The camera doesn't have to move around. And I'm not in the way for the heads down in the front here. All right, so where did identity start? I'm sure you probably all remember this screen. Maybe not this exact screen. But who saw this? Maybe about 10, 15 years ago when you signed up for a new service and they said, hey, we can probably find all of your friends and really easily connect you on this social media platform of choice. Just give us your email address and your email password and we'll log into your email account for you. And we'll go through all of your contacts and we'll find out to see if any of those email addresses exist in our system. And if they do, we'll automatically invite them to connect with you on our system. And everyone thought that is so convenient. So everybody typed in their email address and their email password. How many people typed their email password in? I'm so glad to see there are no hands up. So how did this work? Somebody who come along too. So there's your social media provider on the right there. Somebody comes in and logs in and passes their credentials across. They then pass those details directly to Yahoo Mail, Gmail, whoever the email provider is. And they pass the credentials, your username password, straight in. Which then means that they can return the address list. Or worse still, maybe just scour every single email to see who's emailed you to see if those email addresses exist in the system as well. Pull all the email addresses out and then do some kind of comparison with all the users in the local database and do some kind of match up there. So obviously the thing that we don't want to this point, the really worrisome part is that your credentials are on the server that should never know them. We hear every day, don't share your passwords with anybody. Banks are telling us not to ever tell them what our security pins are if we've got an external device. We're very aware nowadays that sharing passwords is a bad idea. So whoever thought that asking for it in the first place, especially a big social media platform like Facebook, did it, LinkedIn, did it. I don't know if Twitter ever did it, but the big platforms are doing this. Convenience always wins out. And that's something that we as developers need to remember when our customers, our clients are using our applications that they will do whatever's most convenient. And if writing the password down on a post-it note and sticking it on the monitor is the most convenient thing to do, they will do that. The advantage is they'll only need to write one password down on that post-it note because they use it on every site. So what's the better way of doing it? OAuth came along. So we thought we need a way of allowing systems to talk to other systems on behalf of somebody else. Can we give a third-party system authorization to do something in our name? So how does this work? How does OAuth fix the friend-finder issue? So you head off to the social media site and you log in and you want to get some kind of information out of your email account. The social media site will send back a request to you or rather your browser in this case, which is actually a redirect which takes you off to the email provider. The email provider then asks you to log in and you provide your credentials only to the email provider. Email provider then logs you in, creates some kind of token which returns back to your browser and your browser can then send that token back to the social media provider. Social media provider can then take that token and make a request passing that token to the email provider for the contacts and get the contacts in return, which you can then do the database you stuff with. So the magical part here is that you'll see that on that side there, on the untrusted, well actually that's possibly more trusted, like the server side, the services that we as users, as web browser users don't see, we never pass our credentials over there except to the endpoint that needs it. The email service that you use is obviously allowed to know your email credentials so that's how you log in. But at all the times you've got this token and this token has an expiry, it has certain credentials around it that means that it's harder to be reused by other people and because it's only ever passed server to server here with the exception of via your browser, it's very hard for a third party to get access to that token. I say very hard, it's not impossible. But beyond the scope of this there are ways around that as well. Now the interesting thing with this is for authorization, not authentication. So what does all of this allow us to do? It allows us to do things like saying LinkedIn can read emails on Gmail. So we've got our two services on either side and we've got an authorization in the middle. I am allowing LinkedIn to look at my Gmail account so I am allowing TweetDeck to post tweets on my Twitter feed or I'm allowing Eventbrite to create events on my Facebook page. Can I get Eventbrite to get my identity from Twitter? A wealth wasn't designed for that. But it's a huge big hole and one of the providers, Twitter and Google in particular and Facebook as well, were looking at ways like how can we actually get identity information from somebody else. We want to be able to create an account really easily in our system without the user having to create yet another whole profile. Can we pre-seed that information? Again, make it more convenient for the user to sign up. The more convenient it is, the more likely they're going to complete the sign up process, the more likely they're going to bring their friends on, the more likely we'll make money out of them. It's always about money. How can we make more money? We need an identity. So this user info endpoint was created. So OAuth 2 more specifically was like the base platform that started this whole conversation between multiple services and then these different providers added another layer on top which is like this generic user info endpoint which allowed them to get more information out. Again, using that token mechanism. So if we look at what we had before, ignore the bit at the bottom that's supposed to be hidden at the moment, but before we had this request to, for example, get contacts and you have this token and you pass it in the header as a bearer token and the response will come back in some kind of, I don't know, XML format or whatever with a list of all the contacts. And there are standards for contacts. We've got vCal and vCard for calendars and cards and there's ways of making sure that there's some kind of interoperability. What they did was they added this other one on called user info. So there was this user info endpoint that could be at slash user info or there was another standard, standard because there's two now. There are actually a whole lot of different URLs for the user info endpoint and we don't necessarily know exactly what that is for any one given provider and also the response we get back, there's another standard for that. You might get an XML document or a JSON document or maybe even a plain text carriage return, SAML, they're not SAML, actually it could be SAML response as well which can carry some identity information or it could just be like a name equals Ben, carriage return, plain text file or CSV. So you had to know who you were talking to in order to know how to decode the information to come out and it was all very messy. But if you knew exactly who you were talking to then you could sort it out. But it was still early days. This is where OpenID Connect came in. So this was basically the standardization of that user info endpoint. I found a really nice definition of what OpenID Connect is and when I paste it into the screen I hate putting lots of text on the screen because then I've got to read it out and you're all reading along with me and it never works out well because you can't concentrate on what you're reading because I'm talking and I'm talking therefore you're not reading either properly. So I took this and I broke it down into the key line. So OpenID Connect is essentially a simple identity layer which sits on top of OAuth 2. It's designed to verify identity, obtain basic profile information in an interoperable and REST-based, REST-like manner and then using JSON as a data format for the response. So there's still a lot of variables in here like what does the JSON format look like? How's the GET request made? What's the versioning for the URLs? Is it a POST or a GET? But you've already got these six main attributes that if you meet these then it's OpenID Connect which made it much easier for us to interoperate. So if you've got another party that you wanted to have as an identity provider of sorts it was much easier to modify your application to use that and in fact a lot of libraries would then start taking account of that for you. So that's where we got to. That's kind of the history up to where we got to with OpenID Connect. But one thing I'd like to have a quick look at here now is the bit about JSON as a data format. So JSON itself I'm pretty sure you're familiar with is like a key value hierarchical data storage of sorts. But in order to provide identity in some kind of secured fashion like you get this JSON format of an identity how do you know that it hasn't been modified at any point? Because remember that it goes back to the browser and then the browser sends it off to a third party. So JSON web tokens are a way of using JSON to provide information in a manner that can be readily verified as being untampered with. Has anybody here familiar with JSON web tokens already? Has anybody actually used them? Has anybody understand how they work? Interestingly one hand went up for the third question. They usually get smaller but... Okay, so this is a JSON web token. You're welcome. Thanks very much for coming. Most people look at this and go, oh yeah, cool, if they've already used it before and other people just go, what on earth? That's not JSON. But if you, I'll just do a little bit of highlighting which I'm not sure you can actually see on there. But I've made the dots yellow and you can see there's three components and each one of those components is base 64 URL encoded which if you decode makes them look a little bit like this with the exception of the third part. So you have a header, you've got a payload and you've got a signature. And the signature according to the header is a HMAC 256 hash of the header and the payload. You can also use RSA 256 encoding or hashing. The difference of those being HMAC will be like a shared key. So every system that needs to verify or create JSON web tokens will have the same password. Whereas RSA is a public-private key. So if you're communicating with systems that are out of your control you don't necessarily trust them entirely. You'll probably want to go for the RSA. In a lot of cases you can probably argue that RSA is a better option but HMAC can be useful depending on your particular setup. And then in this case we're looking at an identity token so you can see the subject, SUB. So there are a couple of keys in a JSON web token an identity token that are kind of pre-reserved. There's no enforcement about what goes into a JSON web token but there are some that you should use for only one purpose and you shouldn't clobber with other information. So SUB is one of those, that's the subject. And in terms of an identity token this is the response that you get back to uniquely identify a user that's logged in. So every time I log in, no matter whether I've changed my name or my email address or my password or anything else every time I log in to an identity provider and I get an identity token back that subject should always be the same. In this case I've got name, job title and region which are user characteristics, user attributes you can make anything up you want that goes into JSON. Just try that if you search using your favourite online search engine I'm not going to promote anyone in particular but DuckDuckGo is pretty good from a privacy perspective. If you search for like the keys that are semi-reserved in JSON web tokens you'll get a list of those. And then IAT or issued at is another one. You've also got EXP for expired and a few others so that's basically like an epoch seconds since some date in 1970s. So you've got your identity token and then you also have an access token. So in this case it's less about the identity we do have a little bit of identity in there but this is the person who's actually logging in or the person who wants access to a third party like an API for example. We'll also have the issuer so we know exactly who issued the certificate which allows the lying party or the client that's consuming this access token to know well it was issued by this provider and I know that I trust that provider. It also has an audience. AUD is another reserved one so audience is who's allowed to look at this token which is an interesting one because by design our plain text anybody can look at it you could send it to any endpoint you want and the endpoint can use it if it wants to but if you're writing an endpoint like an API that's accepting an access token then you'll want to make sure that access token was destined for you. If you don't care then you're probably not the end point that it was destined for but you can still use that information that's fine. The interesting thing at that point is that if it's not destined for you and you write an end point and you accept a JSON web token from anyone then you don't know what key was used what pre-shared key was used in the hashing algorithm therefore you can't verify the signature so the information might actually be invalid. Now if we just jump back a couple of slides so this bit at the end here the bit that starts where's my mask on over here after this dot here starting with a capital A essentially you take the header and the payload and you put it through the HMAC 256 hashing algorithm using a shared key and then you base 64 year old encode that result and that's what goes in there so now this means that you can send it to any other endpoint, any other consumer of a JSON web token and as long as they know what that password is they can take the header and the payload they can generate their own signature based on those and the key they already know and then match it to this signature then you know the data hasn't been modified otherwise I could go into this one here and I could change my job title to CEO and maybe that would mean I could pay rise I'm not sure so where to beyond this I thought the best thing here is just to throw a lot of information in your face and talk about how this all kind of comes together and this is the last slide but I'd love to continue your conversation and see where you're using it and where you're going from here and what kind of questions you have around identity but if we look at the setup here we've got the identity provider in the middle there that's this one here so you've got your identity provider and you've got all these tokens floating around within your service oriented environment or between multiple different third parties however you want to architect your system you've got you've got an API down here that you've written which is accessible from your web applications and also your mobile applications to the cloud and you've got your tokens being passed around here and the key thing here to notice is if you see those two orange lines those lines that went orange those are the only two authentication routes so that's the credentials being passed from the web application or from the mobile application directly into the identity provider the identity provider is the only system that ever gets your user's credentials where tokens manage the authorization identity so your authentication identity and also the authorization components of what that token allows each system to do on behalf of that user the other thing you'll notice on the right hand side is we've even got Active Directory I don't know if that's an official Active Directory logo but we use that for Federation so you can federate out to other systems you can link that back into the identity provider you could add in things like multi-factor authentication because it's all controlled in one spot whether or not you're using something like Auth0 or you roll your own or you get key cloak and run that in your own environment or you go to another identity as a service provider there'll be a certain number of features that you can use at that point to enhance security even more without having to modify all of your applications because all your applications really care about now is do I have a token, is it valid and then it can go from there so I was the Auth0 dashboard just to go through some of the kind of options that you can have applicable to other providers as well which I'll be happy to do but if anybody has any questions about what I've gone through already I'm more than happy to take them just How do you implement secret governance printed with a large parameter let me bring up a whole different slide show why you shouldn't care about security you're getting a double whammy tonight let's have two presentations, why not why shouldn't you care about security I'll give you the short version of why you shouldn't care about security because that's all zero's job you shouldn't have to care so there's the tagline but here is how let me see if I can find the right slide is it even this slide show maybe it's a different one it's a good question I don't think it's actually this slide show what I'll do instead because this is the way I like to do things I will stand in front of you and I'll gesticulate and I'll move around because that's a great way of helping people understand how things work so you have your browser you've got a big cloud here that you connect through and over here you've got the website you're trying to log into and right over there is when I get too close to the speaker and I get really bad feedback so I'll stand back a little further and then walk into a table so when somebody logs into your website so imagine this is your website you're logging into the table is the identity provider so somebody sends a request to you you already have a relationship with the identity provider setup so in most cases that'll be two things if it's a HS256 so it's talking specifically about JSON WebToken type token stuff if it's HS256 we both know the same password I also have a client ID which is generated by the identity provider and I know the URL of the identity provider so what happens is I have a client ID and that's public information to all intents and purposes so you've just made a request to log in so I then take that client ID and I send it back to you to your browser your browser is then told to redirect down here with that client ID so it sends a request to the identity provider with the client ID so the identity provider now knows which login form to present because it's the one that looks like your website because you've customised it to look like it it also knows which database to look up users in because it's linked to our client ID so you log into the login form you then log into that server down there it then returns to you an auth code so the auth code is somewhat like an opaque token it's basically a string well it's totally random it gets sent back to your browser but that auth code by itself is useless that auth code is then redirected by a browser back to your website so your website then has the auth code and it's also got the pre-shared key with the identity provider with the URL of the identity provider so it makes a request to the identity provider saying for this client ID with this pre-shared key and this auth code that I just got from a browser is that a valid login so the identity provider at this point does remember that it just sent you that auth code which is ABC for example and goes okay I can link that up so John has just logged in I'm going to create a JSON web token for an identity and possibly also an access token HTTP a point to point server to server request which is sent via post so it's not a callback so you've got all sorts of things in there that make it a lot less likely for somebody to be able to intervene and get those tokens the tokens are then stored in memory you can persist them if you want certain security implications around that but it persists in memory on the server the client meanwhile your browser already has a session, a cookie session established so now every request that comes in I get the session, I re-instantiate the session locally, I've got your tokens therefore I can now talk off to Twitter or whichever other APIs use these tokens so the auth code is used long story short to basically send a, it's almost like a one-time password to allow the server to ask the identity provider for the tokens so that makes sense how do you expire those tokens with the website two ways you can do that the first one is you can put a really short expiry on them so I would generally have an expiry of I don't know, 5 minutes depending on my use case in some cases I would advocate an expiry of 20 seconds depending on whether I just need to make one call to this really high risk service and if anybody else managed to do it then I don't know I could kill somebody it's a really low risk one and I'm happy for that session for that token to last a day in any event you can also make a token, a refresh token so the identity provider so there's scopes and the scope you'd have like profile for example is a standard scope for give me profile information about the user and then you've got open ID as another scope which is what then generates the JSON web tokens and the access token then you get returned a refresh token which means that because the server can now use your token even when you're not logged in to talk to another system if that token expires it can take the refresh token which is a lot longer expiry, it could be like 30 days or 6 months or whatever it can take that token, it can talk directly to the identity provider and only to the identity provider pass it the refresh token and say the last token I was using as expired give me another one and then it'll return both a new access token and a new refresh token so that can continue happening in the background so I would advocate having working out what your risk profile is for if the token gets breached what's going to happen what's the worst that could happen and define your expiry so you're comfortable with that if you're in a situation where you want the token to last a day just because of the environment you're running it in and the way your users interact with your application but you need to be able to cancel the token a lot faster then you can implement your own token blacklisting so for example if you had a token that allowed people to log into your corporate email but then you fire somebody at 2 o'clock in the afternoon and you needed to cancel that token immediately you would add that token into a blacklist and then you would have some kind of mechanism whether it's a centralized gateway or the application itself to say ok well this token is a longer valid we'll kick them out can you tell me the difference between OAuth and OAuth 2 so OAuth 0 is the company and then you've got OAuth and OAuth 2 so OAuth and OAuth 2 are the protocols yes so 1 and OAuth 2 correct so they move from 1 to 2 and so it's stuck on 2 OAuth 2 is the one we use nowadays OAuth 1 is actually slightly different it's not really like version 2 of OAuth 1 it's actually it's quite different but we don't use OAuth 1 anymore the architecture is quite different yeah and nobody has used OAuth 1 to 2 is it a abandon? yeah it's not really in use it doesn't solve the same problem as OAuth 2 does OAuth 2 was more around OAuth 1 was essentially like the great idea that people had that they tried to implement and it had a lot of security vulnerabilities but people used it and it was a great way to get us to think about how to do authentication in that way, in a better way and then OAuth 2 was a re-implementation that actually worked and that's the one we use OAuth 0 is the company and what about OpenID? OpenID and OpenID Connect so OpenID is again all the technology and also very little to do with OpenID Connect OpenID if anybody remembers like 10 years ago or so we were talking about this before it was very popular for people to install like plugins on their websites that would provide OpenID capabilities and essentially what it was is that you'd have a line in your like the header of your HTML document so my OpenID handle would be hdps.com and then if I wanted to log in somewhere that system would load that web page look for the meta tag in the document that would define who my OpenID provider was which could also be WordPress in this instance it would then redirect me to that endpoint which I would then log into and then it would send back the identification or the authorization in the response redirect so it was whereas OpenID Connect is the standardization and proper implementation of the user info endpoint plus a few other things on top of OAuth 2 so OpenID Connect only exists in conjunction as stacked on top of OAuth 2 without OAuth 2 underneath it it doesn't work so a lot of the discussion around this always gives one point that I want to get your idea on how do you end up storing the security piece I have my OAuth setup and then we go through my GWG you know my out servers does the verification but for doing all of that I need to have the signature the security can verify the signature so and every company or rather even in the company every project starts having its own solution to doing this same product in the different companies so what would you say would be the most safest and simplest way to so just to clarify you're talking about where to store the pre-shared key in an HMAC hashing algorithm so by and large if you have any questions about whether or not it's secure you probably should be looking at RSA hashing and using public-private key can you give me an example of why it wouldn't be secure in your particular case no it might be secure but for example even if that key is a sometimes in some projects you might see the key lying around in a properties file sure so even if it's safe from everyone else it's not safe from the developer well so thinking about a Laravel application for example I come from a PHP background and I was recently integrating Laravel with Auth0 so I would have it in my .env file which means that those are variables that are instantiated only when the server starts and they're in environment variables so they're in memory only they're persisted to disk because they're in that file but that file never gets pushed into a Git repository therefore it should never end up on GitHub or Bitbucket or anything like that from a developer perspective as a developer I wouldn't be using production keys anyway I would have a key that is for me to use in a sandbox or a staging or a development environment the only person that should have access to the whether or not you're doing it through .env file or you're injecting it through Apache configuration or whatever mechanism you're using to manifest this key in memory so that the application can use it the only person that should have access to that file is the person who's got access to the production server and if you don't trust them to have access to the production server then you've got bigger problems and depending on this so I work for an enormous firm so what we do is we integrate a lot of social media because when someone makes a purchase for example we also want the different same thing of social media so we have all of the tokens from the different social media websites because of the nature of tokens we assume that these are safe things to store in plain text so we put them on a database or somewhere on redis or some cache or something like that do you think that's safe? I just want to evaluate whether this premise is safe because that's what we're doing right now so I have two conflicting answers for that the first is that I think everybody should treat every token as breached so if you have an access token you should treat it as a well particularly identity tokens access tokens you want to be even more particular about so you're looking at an access token to talk to another system so in that case I think you should treat the payload as breached but not the signature and even then because the signature is based on a pre-shared key it's not terrible for that to be breached now of course the hard part is that once anybody has that they can use it against any system so that's something you don't want to have but if you have the mentality that it's breached at all times then that puts you in a defensive position so you're more likely to consider the negative outcomes of that now the flip side to the answer of that is that I forgot what the flip side to the answer of that was you look like you want to say something too maybe just to add on top of what Ben mentioned so I think this too also makes a subtle distinction between tokens and keys so keys are used to generate tokens keys in terms of storage depending on the type of application if it's production definitely you should not store them on this they have to be stored under an HSM actually you guys have to deal with that term that's a hardware spirit you know like a black box or a coffin that nobody can actually have where it acts but that's more of a specialized device that really depends on maybe if you're doing e-commerce or like how it acts so an alternative is to look at I guess you know cloud providers that kind of like offer similar things so I would rather use maybe an Amazon cloud or like this or that but you also have to recommend if you do with that approach because then the question is you're basically subjecting your key to be stored on a different computer but that's also a different conversation so it's to keep the focus on what you have in terms of storing the keys if you want it to be really secure never storing on this I guess then like you said maybe for development that's where it would be fine and then definitely production has to be stored on a much more secure storage facility on the point of tokens just one second I'm presuming they're going to be post-editing this so I'm going to quickly summarize what you said just for the recording so basically it was making the distinction and correct me if I'm wrong or if I missed something it's making a decision between keys and tokens and specifically when we're looking at keys in a production environment never to store them on disk the best way of doing that would be to use something like a hardware security module comes at a cost but it's a great way of storing that information in one place that the application can then get access to in a secure fashion that means that if the actual system is breached somebody ssages into your server they're not going to be able to get access to that those keys that's right and I guess on the second point I think very quickly so when we talk about this there's a reason why there's a tissue in this time and exploration because again a token should be just you know one type that's why it's kind of like a token there is a I guess a validity where you can use that again depending on what kind of application you have as I mentioned depending on the risk that you're trying to manage it is really about managing the kindness that we have a token that has an indefinite time because the moment that you do that well in fact there is a token that's called a password that has an indefinite time while you might have a policy or kind of like a HR policy to better say that you have to change your password in a few months and whatnot but it's still I think based on the fact that you should always have a short time to get a bit so just to repeat that for the recording when looking at tokens the main things to consider are again the issue time and the expiry and making sure that the window of validity is short enough that it meets all of your security risk analysis while being long enough to actually be usable in the context that you're using it generally you don't persist access tokens that's right so you wouldn't persist access tokens you'd store them in memory if you're storing everything on your server then your risk is a lot lower than if you've got a single page app in a single page app you would certainly only ever store any kind of token in memory so that if somebody refreshes the page or there's a cross-site scripting attack it's really hard to get that token out there used to be a recommendation that within a single page app you store the access token in local storage which is now highly discouraged basically because we don't know what browser add-ons people are running either if somebody's got grease monkey running and somebody's managed to inject a script that then scours your local storage and sends it all off via an XML htpxml htpxml request off to a third-party server then they can dump your memory and shove it all off to another system so there's an issue there that they could dump the memory and look at it but it's harder to analyse than if it's stored in a cookie some people actually store them in cookies that scared me that I heard that so definitely not cookies ideally not in local storage either and of course if you're establishing a session with a server in any way make sure your cookies are htp only because if somebody does manage to get a cross-site scripting attack on your single-page application they can run arbitrary javascript in your application so if the browser won't give the cookie to javascript then you're more secure in that respect as well any other questions? yes or accessibility then is the security good enough and go off later? if you're implementing what sorry Tomcat I'm not familiar with that I'm afraid maybe we can go into it afterwards I'll be happy to find out more about what you're doing how you're using it we can work that out this is where you can actually put in your password or even hash it so you then also can specify your role and user so anybody that is outside this role and user and the passwords they will not be able to access to the pages that sounds more like an access control list mechanism as opposed to an authentication system itself so it's all about in this particular case it's about where you're storing the identities of your users how you're authenticating them what kind of mechanisms you're using to store those credentials what multi-factor authentication mechanisms you're using on top of that whether you're connecting to an active directory server to feed that information what all Zero provides is more around the whole identity platform picture of how to work out who's using the system you can do access control in there as well but it sounds like what the Tomcat thing does is more around knowing who the user is and then doing access control to certain areas it sounds like they're different things so you would potentially use something like Word Zero in order to authenticate and provide information back to the Tomcat server so you're not storing your usernames and passwords in your database you're having them managed elsewhere but that token then allows you to identify who the user is and then go on to work out which web pages they're allowed to access so that if I have something like that they're different things so to use an example imagine you're going to a bar and you want to buy a drink so it sounds like what the Tomcat stuff is doing is working out which drinks you're allowed to buy are you allowed to buy gin and tonic or only coke that depends on who you are, how old are you, what are your credentials so one way they could do it is you go to the banter at the front door and you tell them your name and address and your parents phone number and they can then call to make sure you're at the right age and all these other things that's kind of like managing your own authentication or you can have a driver's license and you show them the driver's license and it's not just an authentication printed on it but it also looks like a Singaporean driver's license and has got the holographic symbol on it and that's like the token so Auth0 is like the driver's the driving authority the licensing authority no because what Auth0 I mean Auth0 can do the authorization stuff as well but what is doing in what the Tomcat stuff that you're talking about is doing is the authorization after you know the identity you can either manage all the identity yourself and to be honest one of the biggest competitors that Auth0 has is roll your own so you can use the login mechanism that you already have within Tomcat and the system that you're using or you can use Auth0 to provide that and you would still then use your realm data to work out what they can access but the login is separate the advantage of separating that out into an identity provider is the ability to reuse that within other systems that you also have to login and out of and you can add things like multi-factor authentication, social login out of the box are we talking about Auth or Auth0 because you asked about Auth0 at the beginning and there you reference Auth now Auth itself is Auth itself is almost like the realm type thing but it's a a trustless environment so there's two services that trust each other because of Auth but service A doesn't need to trust service B whereas in the Tomcat realm environment I imagine you probably need to trust all of the back end systems to have this shared access control I'm I'm guessing a lot of this because I don't actually understand the technology and maybe I'm not the right person to answer these questions for you What you're saying is the authentication and authorization Please Steven, another question It wouldn't be slightly off topic but sincerely Could you talk a bit about the SOC to compliance and just like maybe like a small primal because we have to direct ourselves to that but we don't know where it starts I'm the wrong person to ask that SOC2 is just a certification The better question is How does someone fail when it comes to authentication What goes wrong? Why would it not get certified? It's beyond me Yes Let's say that you have an application and you have a business partner who is operating an identity supplier What is the burden for them to implement The JSON Web Tokens So they're an IDP already and they don't currently use JSON Web Tokens So what does he ask? You're asking them to do a lot? I don't know what they currently do If they currently provide an opaque token for access control then I don't know It's a black box question I don't know what their data structures like what their framework they're using I mean technically you could argue that if they've got the data already they just convert that into JSON and they sign it and they send it back to you but you're going to have to have extra endpoints for you to be able to send orth codes through and it could be massive, it could be Let's say you've done that with one partner Originally they were using held app or shiblet or something like that and you came along and you said okay what we're going to do is we're going to use these GWT and you get through that exercise now you have a second partner Can you just duplicate it for the second partner, the third partner or do you have to start a whole new dialogue and re-engineer everything all over again Is it different for every Putting my sales hat on what you do is you get Auth0 to provide all the JSON Web Tokens to you and you have a SAML connection between Auth0 because Auth0 can also be an identity client it's an IDP and an IDC and you can actually have your identity provider provide credentials to Auth0 and Auth0 will then use that as verification you're logged in, generate the JSON Web token send it off to your application Done One gateway which is Auth0 and then they're just different identity suppliers but there's still some part that has to be implemented on their side Well they're currently already an identity provider so they just become an identity provider to Auth0 Thank you So if they support SAML if they support one of many authentication protocols then you can probably plug it in as an extension towards ERA You're welcome I have to remind my boss to give me commission Can I ask a business question Is it a viable business to become an open ID provider Is it a viable business We recently got a fifth round of funding for 103 million US dollars and we're now valued at a billion dollars so I think it's viable Auth0 There's also Okta AWS Cognito Azure has its own identity IDP Ping HID So there's a number of other companies who also do the same thing So there's at least six there including Auth0 I reckon it's probably a bit of money in it But in Azure Are you aware of anything Auth0 Yeah And that HID But it must be Auth0 I was just once at this meeting Yeah exactly I think that's the main crux of that question It's not on the methodology OpenID Connect Auth2 Or actually That's an open standard That's why you have different IDP providers Which enables Auth0 Amazons And different types of providers To get a degree on the framework Of how you can communicate And identify The key business there is actually on the identity piece What you pass along With the application And again we're trying As an industry We're trying to move everybody Beyond using the passwords I'm not saying we can totally avoid it At this point But at least you know definitely Try to add to it To make it much more With the application So I threatened to show you I mean I promised to show you What the Auth0 dashboard looks like With the internet access So I can't refresh the page But I can show you the menu items So out of the box When you write your own username Password login, you've got username password login And you're going to have to do your own Password reminders and resets And all of those things If you want to add multi-factor authentication You're going to be spending more time on that as well So by going to an identity As a service type provider You can get a whole lot of things out of the box So in here I've got A list of all the applications Within my so this is called a tenancy Tenancy in the identity provider world In the software as a service type World means that while Auth0 Has a lot of clients I'm one and I'm individual So all of my users are mine It's not shared across When you do login with Google Or login with Facebook for example There's one big database of all the users With Auth0 when you have your own tenancy It doesn't bleed across to other clients So I can set up a whole lot of applications And APIs, I can integrate With single sign-on options Things like active directory Or even Azure online So you can configure it If your company uses Office 365 And you start typing Your email address into login to a system It'll detect the domain part And if that domain matches a certain list It'll automatically redirect you off To login via your Microsoft 365 Account And then come back so you don't have to Have a password within Auth0 either You can connect to databases These are databases that we host Or databases that you host So you can actually use a third-party database Outside of Auth0 for your credentials We've got social which I can't click on I might just get A quick Wi-Fi going Just to show you Does anybody know who HL Guest is? Can I use that access point? Or should I start my own? I don't want to steal anybody's internet access There we go So if I refresh this now Why don't you refresh? It seems to have frozen Any demos? Yeah, but the mass Point isn't even changing Like the Chromium has crashed There we go Isn't this fun? Bet you never thought you'd come to a meet-up And just spend a minute looking at a refreshing page So in here we've got A whole lot of different So I can come in And just automatically enable LinkedIn authentication Give it the credentials that I have For my LinkedIn dev account We've recently added the new Apple authentication So you can use your touch bar for Authenticating or something You can link directly to Enterprise So you could So this is where you'd link into your Office 365 Directly We've got a number of passwordless options So from here you can If it loads Enterprise and standard tool? It doesn't want to load this one But in here you've got things like Authentic A4 SMS May or may not be as secure as you like But Authentic A4 also has Something called Guardian So that if you want to log in It then sends you a push notification And you say yes or no to it To authorize The advantage of that is we've even got an SDK So if you've got your own mobile app already You can build that into your own app So if you're an energy provider For example And you had an application That allows people to see their current Power usage on their phone And then they log into your website And they type in their username and password And they have an app saying Somebody's trying to log onto the website As you do want to go ahead and you go yes And then it logs them in So you can do that kind of thing Yeah Yeah So here's the Duo security that we were talking about before SMS Push via Guardian That's when you can bake into your own app One-time passwords that allow you to use Things like Google Authenticator To a whole lot of ways of making Your system more secure just by flicking a switch I should take my sales hat off again now How many social logins do you support? Lots 520 nodes 40 something I think 2 4, 6, 8, 10 12 13 times 3 30, 42 Approximately If my maths is good and my counting is good But it's easy to just add your own Yeah So we've got a whole lot of extensions as well So you can add third-party extensions That allow you to do your own thing One of the interesting ones is A account merging So say for example you've got a client Who's logged in and they've said My email address is benedekarai.com My password is password First of all Auth0 would allow you to have a password So when you've finally chosen a password Auth0 is actually happy for you to have Like stringency in that If I then log in via Twitter The second time And Auth0 will get My email address from Twitter And it'll notice the email address is the same And it'll say to me it looks like These two accounts are the same person Do you want to merge them? And then once I've merged those Whichever one I log in as You know how we're talking about the subject before Being the unique identifier for a user that never changes Whichever one I use I'm not sure I'm not sure about briefly And I probably couldn't talk To the full extent on what the options are There are ways that you could So we do support things like Detecting impossible travel So if somebody logs in from Singapore And then three seconds later Somebody's trying to log in using the same account from London You can detect that And you can block that You can do things Rather than blocking it You can escalate And you can have optional multi-factor authentication So you can have username password is fine But then if somebody logs in three seconds later From another city on the other side of the world Then say we're detecting some abnormal activity We're now going to send you an SMS as well Just to verify that it's actually you So there's various ways that you can Kind of escalate that security aspect of it I'm just taking out So Google sends us this notification When you're trying to log in from A different device So at some point of time They have this browser fingerprint Or device fingerprint Stabilize to that as well The fingerprint as in You're not talking about fingerprint You're talking about the device I'm not sure to be honest One of the things Like even if we don't You can add that in using hooks I'm pretty sure So we have a powerful hooking mechanism You can write your own javascript Especially a callback We run node on the server And you can run whatever javascript code you want So you could have a Post login Post authentication hook That will grab information out of the context Which I'm not sure if it will contain The fingerprint to be honest Of the device But you could do things at that point That then go off to a third party For extra verification To prevent the JSON response So there's Bot detection Yeah, I'm not sure At least 40 verses of traffic Which is what most of the times Do they have something about that as well? I can find out for you I don't know off the top of my head I wouldn't want to give you the wrong answer You can restrict the IP For example, for the same IP The bot is trying to log in But that's the thing How do I detect the bot? You don't need to detect there Because we're using Auxer here What happens is There are more than 10 attempts 10 failed attempts from one system Blocks right there If there are too many attempts Then also you get blocked Based on IP Not just based on IP Based on the user IP So one problem I have with IP Is the nothing thing Because it usually blocks A lot of company customers As well as the text them as bot And we end up using Conversion special functions So I do not really trust the IP But it's only based on that Then e-commerce No, I'm not logging in Cool Well, unless there are any more questions I'm happy to socialize more And ask questions when I'm not Up As well But thank you all for your time And don't forget to join us for drinks Afterwards