OAuth vs SAML vs OpenID Connect: Protocols Compared for Developers

[00:00:01][Music] just introduce myself really quickly I'm Mike Schwartz I'm the founder and CEO of glue glue is a software vendor we make something called the glue server it's an open-source identity and access management platform and we also make the super glue two-factor mobile app and an API gateway for API security so if you I want to follow us on Twitter we're at glue Federation and on LinkedIn you can just send me a LinkedIn - NY NY mic so it's gonna currently flip in and out so we'll just keep our fingers crossed so I wanted to sort of reverse this so this is a talk on single sign-on sam'l Open ID Connect whoaaah and I thought um instead of me maybe talking at you for 45 minutes but just to get it out of the way we'd start we'd reverse this and I take questions first and then do the presentation after so maybe if anyone you know is coming into this session and has some questions about single sign-on Open ID Connect sam'l low auth any of this stuff any questions like before we start Claire okay any other questions um so we're if you just came in we're doing a reverse session I'm taking questions about Sam will open ID connect an OAuth first and then I'm gonna then I'm gonna do the presentation I'm right in your friend okay so what are the differences between all the above yeah we're definitely gonna cover that in the corner okay so if you're a developer and you're writing software and you need to know what client software you used to connect to open ID connect server or a federated identity server okay cool that's good in front mm-hmm so which is more secure sam'l open ID [Music] okay okay so sam'l was okay why do we why are we using newer protocols and what's the security benefits pros and cons for each I got you okay well in the back how do you audit the SSO and transactions okay okay so audit and application security implications for the federated identity yeah in the front okay which protocol is the best for the cloud okay these are all good questions it's amazing how many questions people have about better effect entity oh and they asked them a lot of different ways so okay so that's helpful for me to understand where you're coming from so let me just start with like the really most basic point I can make which is that the reason that we use federated identity is because we don't want to show that password or expose the secret to the client so we have two actors here the client and the server um the client is the thing that's connected to the person and the server is the thing that's holding the secret you know think password and what what we really don't want to do is have the person enter let's just say the secret like the password into the client because if the client sees the secret then the client can impersonate the person you know the the human and that's not good so trying so that's the point so I'm just gonna give the whole talk away and just tell you like the answer in the third slide so you know in in the 90s we had these authentication protocols like radius and LDAP and they ran on a specific port and we had you know their own IETF drafts for these things and around maybe you know late 90s 2000 somebody said you know maybe we should just use the web as the transport layer for authentication and that way we won't need to define our own port and and we have all this stuff in use in the web anyway and I think everyone agreed that was sort of a good idea but then once we said let's use the web for authentication everybody and their brother thought of a different way to use the web for authentication so in the early 2000s there was this explosion of like protocols for for single sign-on and using the web for an occasion so so in the mid 2000s like okay sam'l became sort of an agreed-upon standard between a lot of different organizations like the big companies like Oracle even Microsoft and then unfortunately in 2007 this this important thing happened called the iPhone and all of a sudden we had a new a whole new paradigm of mobile apps calling api's that just didn't really exist you know the sam'l and these previous protocols were built for like a person using a web browser going to a website and mobile sort of like just disrupted the whole thing like created all these use cases that that sam'l wasn't made for so what happened was is that it wasn't just that that we wanted to invent a new protocol to replace sam'l but there were actually new requirements so the Sam will being a stable spec couldn't be changed so to meet these new requirements in this increased surface area we basically needed you know to either improve sam'l or to invent something new and improving Sam what was not possible because it it was just it is what it is and the vendors wouldn't accept any breaking change so there was really no choice except to move to this new new profile of federated identity around the same time that that was happening there was some other like just dramatic shifts in the UM in the sort of web development world so we went from from being let's say XML centric to being JSON centric I justify my slides okay found them and in general there was also a movement around like being more developer-friendly so when when Sam was first designed it was like sort of top-down security like here's the security that you need to do developers you will all do it but you know some time around let's say the late 2000s Google and others were saying we have to listen to what the what the developers are saying and make our api's developer friendly okay so here was let me see if i mix miss anything signing so in in in sam'l you use you canonical I see the XML that means you make two pieces of XML with different whitespace the same and then you sign it open ID Connect uses a a different JSON based signing mechanism other other another interesting comparison is you know there's a lot of esoteric sam'l that no one ever uses but artifact a binding is one of them in sam'l but there's actually an exact equivalent in an open ID connect the code is used in sam'l with the artifact binding so it really is a direct parallel between samples and identity layer using XML and and and open idea Connect is an identity layer using JSON I talked a little bit about so sam'l this is sort of sam'l 101 stuff but a sam'l profile is takes a number of these different concepts and creates different ways that you could use sam'l I'm gonna skip through this one because we're we're below behind on time the basic idea with sam'l is that you're bouncing an XML file back and forth using the user's browser so there's a sam'l request that gets sent from a website I want to authenticate this person the sam'l server gets that XML and then it authenticates the person and returns an XML back to the website and says you know here's who this person is here's your sam'l assertion it's an it's a neat trick because the the IDP and the RP don't have to be connected as long as the person's browser can reach both it's okay and so in sam'l basically working um you know and and secure if you're using you know web applications it's really those new applications JavaScript and mobile that just were totally unaccounted for and in sam'l use cases so this there's a fair amount of confusion about OAuth and being an authentication protocol so Olaf is actually a mechanism to enable a person to authorize something it's and so this is a sort of a saying but you can have using chocolate to make fudge does not make chocolate equal fudge so using OAuth for authentication you know doesn't make an authentication protocol if you read the the IETF draft the OAuth spec actually says it's an authorization framework note not a protocol either protocol is much more specific so open o auth uses tokens there's two different types of tokens bearer tokens is just some type of unguessable string and when you put that sort of into your request it's really handy and then a JWT is really an assertion it's a JSON that's a that includes a signature and it could potentially be encrypted too so oh F defines a couple of roles the really the three in the middle are the ones you need to think about there's a client or resource server an authorization server the client is the thing that's connected to the person that's either your mobile app or your or your website the resource server is the API so you might have a mobile app you authenticate and then your your app starts calling api's on your behalf so the resource servers the API server and the authorization server is a thing that issues tokens them so those are the three actors in OA and those are the same across all all o of profiles we have some other people who are who are in this we have developers the requesting party would be the person trying to get access to the thing and the resource owner is the person who controls the the thing so you probably from the user perspective you've used OAuth so this is a an authorization request from Google Google you can see it's too small to see in the URL but actually OAuth use in the URL so Google saying can this application CNET what do they want to do they want to see my age and language so it's an explicit consent by me this is a nice trick that was hard to do in sam'l so ooofff defines these things called scopes and each scope maps to a some permission or some permission description you might want to display to the user so if we had a scope called calendar we might want to send a message to the user that says this app is going to update your calendar so Olaf uses scopes to sort of map authorization policies this page that I'm referencing Google publishes a list of basically every scope that's needed to call every API and sometimes an API might have varying levels of granularity with what function within that API are you trying to call o auth you might have heard of these things called grants a grant is a flow you would have a different flow for let's say a client that's just doing client authentication think of an IOT device that's calling an API there's no person in that loop we have this device calling an API so that's one flow we have a flow where the person's using a browser we have a flow where the person's using a JavaScript application and oo thievin defines this flow you're not supposed to use called the resource owner password credential grant that's where the client actually has the password and wants to validate it so grants really you can think of them as different flows so what's interesting about people think of sam'l as being you know very really a big spec but actually that people don't use 90% of sam'l so the 10% that people use is actually really short an OAuth has gotten way bigger than sam'l currently 16 RFC's and 16 draft dark seas it's covering a lot more these basically as new vulnerabilities are announced mitigations are are published and and standardized and so you know basically OAuth is just covering all these new use cases that we need to cover so what's interesting is that with all of these specs in o'a there you won't find it anyone that talks to you about how to do the user authentication so there's no equivalent of sam'l in these OAuth specs ironically the OAuth group didn't want to take that on and so they used the open ID foundation to create a profile of OAuth 2 that serves as an identity layer like sam'l so really you could take the 16 draft rfcs or the 16 rfcs and the 16 drafts and then add an additional probably six or so from the from the the jose group that's the JSON object signing and encryption and then probably another six packs from open ID foundation and you sort of get one body of like what's the current state of like of authentication and federated identity Connect has three main specs one is called core and that explains how do you authenticate a person one called discovery that's the equivalent of sam'l metadata um so a sam'l metadata is is like an XML document describing the services and the keys of the of the entity the IDP or the SP Sam will have our Open ID Connect has a dot well known address that standardized that returns a JSON object that tells you who is this IDP and what crypto does it support and where where it's keys and what are the URLs for its different services and client registration standardizes oo auth clients used for authentication so Open ID Connect is oo-oo to it profiles OAuth 2 so it created adds in more details to create a user interval implementation of OAuth 2 for for identity for both authenticating the user but also for sharing formation about that user from the IDP so what people get confused as they say well we have these three actors in oh uh you know client authorization server resource server we only have two in sam'l we have the IDP and the SP so what happened like well what happened is is that the thing that we call the open ID provider is actually smushed together the RS and the a s in one unit because it's both issuing the token and serving up the resource I'm called the user info endpoint that's where we give up who is this person so just walk you through like the difference between a JavaScript app and a a server-side app there's one huge important difference and that is is that there's no client credentials so if you're using a JavaScript app you redirect the person into the identity provider the person authenticates you get back a token but nowhere in that do you present your client secret you tell the client you tell the server who you are which JavaScript out but you don't present any secret in the code flow which is used for if you have a spring app or a ruby on rails app then you're using a server-side app where you know the code is on the server in that case the server can protect a secret so the server can use either client ID and secret we see used a lot in OAuth but potentially you could also use private key authentication open ID Connect defines an asymmetric authentication mechanism for the client so that it doesn't have to have a shared secret with the server so I think that pretty much covers it let me see let me go back to the questions and see if I can so one of the questions that Clara's question was about relative adoption of the protocols so so that's a really good question the adoption of the protocols I would say your enterprises large enterprises today are most likely to have saml if they have an older older version of Active Directory they might have Active Directory Federation services popular SAS services like one login octa and ping one or all using sam'l and only sporadically supporting example website service our services are mostly supporting sam'l so on sort of the enterprise you know type application and SSO front sam'l is pretty prevalent however if you talk to developers who are writing new applications then it's almost like a hundred percent open IT connect like nobody wants to write any new open and sam'l apps I'm so new SAS providers who are just launching our great thing about supporting sam'l and application developers who are doing consumer facing applications or internal facing applications they don't want to mess with Sam well if they don't have to so if you're writing an app you're you want a JSON REST API you don't want a big XML thing to parse and canonicalize the other question was about client software so that's a really interesting question there is quite a bit of client software out there in you know I look at it as we have plug-ins for web servers is one category and then we have libraries in the plugins for web server side open ID connect has plugins for Apache and nginx sam'l there's Apache I'm sure there's an engine x1 out there too but I know Apache and an IAS there's a couple of proxies that support open ID Connect I know the Khong API gateway supports it if you're looking for a web proxy for that on the client software side open ID foundation has a clock the client certification program so libraries can get certified and there's basically client libraries for everything like you can go to github and you can find Ruby JavaScript node go like whatever your programming language is there's an open ID connect library for it which brings up an interesting security challenge for organizations which is if my developers are using a bunch of different libraries we grabbed off github how do we know that if some security vulnerabilities announced in a auth that we can patch that library and if we patch the library do we have to Riku a the app so glue has introduced some client middleware called ox d which is shareware licensed that it runs as a service I'm either essential web service or as a service for listening on localhost and enables you to update the software using after yum and then keep the application interface stable so there's a bunch of approaches in in client software I have another talk where I just talk about how to write secure client software and I was the one thing I'll say is that if you have a really good server like the glue server or ping and you do a really bad job like writing a client and you don't validate the state and you don't validate the signatures and you just sort of like oh there's a JSON with the person's information I'll grab that and create my session you can totally undermine the security of any authorization server if you write a bad client so that's an area that people don't think about a lot somebody had a question about audit and basically how do you I would just say in general in an SSL system there there could be hooks to certain important events and and I think when you're evaluating like a platform one of the things you should look at is how easy is it to customize does it mean I have to fork the code and manage my own distribution or their convenient interception points that allow me to maintain my customizations in a standard way a lot of so in terms of telemetry like what telemetry is thrown off by the server varies greatly depending upon the distribution it's not really a protocol specific thing and there are and yeah and it's it's hard to find data on like what you should you even be looking at you know what's unusual what do you want to log so it's sort of like an area where I think a lot of companies just are looking at traditional web celebrity telemetry type of information so in front we had a question about security well you know it depends it's it's it's not a question of is it secures that not secure because there are different the question is is it secure enough for the transaction that you're you're undertaking so open ID Connect philosophy was to keep simple things simple but to make more advanced things possible so you know if you take a the JavaScript flow that we're talking about the implicit flow not terribly secure but totally appropriate for lots of types of transactions and then but if you look at the new profile that was developed for banking I'm called fappy the financial API is that aligns with PSE too they used every security feature known to man and then a couple and it's actually if you do all that stuff it's way more secure than anything we're doing today you can actually rate the flows from from one to five in terms of security so plain Oh auth by itself would be one the worst and then implicit flow would be number two that's the JavaScript one it's actually better than author than ooofff by itself because oh aw just gives you the state and that's it implicit flow gives you the ID token so you have a signed assertion then you have code which is better because you can do client authentication and there's two above code called hybrid one the hot one hybrid flow above and it's signed responses so the code itself can be hashed and signed so there's some extra security hoops you can go through above code and then there's a there's a second hybrid flow which involves request signing so when you send the request that itself can be signed so that the IDP knows that came from the client mmm and then there's other they want to create a complete security profile around all of how you use all this stuff and to have it standard and interoperable is really difficult and that's why they took that on at the Open ID foundation with the financial api's because in Europe the PSE two regulations specify these api's for basically transacting payments and they specify the security around it and the profile sort of aligned to the requirements set forth and PSE 2 for the practices and procedures and that you need to do to both the client and server side need to do good well everyone in the OAuth community knows that this is they're just just it has a specific use case in a trusted network maybe there's a use case for it we always say don't use it it's not an SSO protocol anyway because SSL protocol always involves a redirect so we can keep the session in the browser so and it is you're right there but the resource will you know what you can go through the Open ID Connect spec and you can find stuff about like autonomous IDs and delegated attributes that'll never be used but they're not taking it out either so there's the best practices that have emerged around the you so auth some of which is published as RFC s there's a really good RFC around best practices for mobile Oh a 2 written by Google and others that you should read and it basically suggests the use of a protocol to enable like almost like a one-time secret to be generated rather than using client credentials called pke there's a ton of best practices around it oh and and also remember that the the federated access protocol is how we send information about who authenticated to the app there's another of super important part about how did we authenticate the user I'm in the first place and how did the identity and other stuff get it get granted yeah so there are various ways you can impersonate a user if you can intercept any of these pieces that flow back and forth between the client and the server you could potentially impersonate somebody and fraud detection is I think is really important to do out authentication time but just talking about outright hacking if you didn't protect them all of the communication between the server and let's say the authorization server and its database and the client and the server the assumption for all of this stuff is that there are secure communications between the pieces but if you could intercept a code or a token you potentially could impersonate a user but delegation to a customer service that rep it's really sort of an implementation detail of how do the applications going to support that and how are you gonna make that happen but so does everybody know why they wouldn't use LDAP for authentication anyone still using LDAP for centralized authentication for web apps ok yeah and what would our I guess I can give my last slide so the glue server if you want to try out open ID connect or sam'l we you can go to Glu org if you want to get these slides um I created a short link on gluco last con 2017 note there are there is glue as glue org we just used that gluco for short links so there is no glue code where where glue org glue is a it's open source it's free open source so you we have packages for Debian Ubuntu cent OS Red Hat you're basically doing a yum install glue server and then you run a setup script and and you have a local instance deployed it deploys on the cloud etc the clients I recommend if you just want to get started in in figuring out like hey you know how could we do federated identity you want to write a test client if you're a developer the one I suggest is the Apache filter for open ID connect it's called mod off open IDC and you know if you just want to say I have a website and Apache and I want to protect this website you know with my central open ID provider that's probably one of the easiest test to do glue also has a JavaScript client that's pretty easy you can just you can do the authentication all and without any coding just saw on the HTML and yeah so and and feel free to send me a LinkedIn also so we either follow us on Twitter you go back to that we post a lot of good stuff and we post not just stuff about glue but we also post every industry news piece relating to authentication like if there's elbow authentication in the future we'll we'll be tweeting about it first and we generally tweet out if you're looking what are the latest RFC's ietf like drafts etc we tweet that out and then a bunch of industry articles and occasionally of a glue blog which we don't write enough of and yeah and if anyone needs more info about glue everything on the glue site funnels you to schedule a meeting so if you feel free if you think need more info just just let us know okay thanks everyone you [Applause]