SSO for Web APIs

[Applause] [Music] okay welcome nice to meet you too one of the most annoying topics of development security okay my name is Nico Coppola I am from Germany I'm a frilly ins guy and I'm more than 20 years in IT business I recognize that a few weeks ago when I got my new fitness trackers has a very small display and I have to put my wrist far away from my eyes so I'm getting pretty old besides my day job I co organizing local Java user group and um start it's never Frankfort and speak occasionally at tech conferences all over the world and last year I wrote a book about service computing in the cloud but that's not the topic how we talk about today and of course as every speaker and developer whatever I I'm on Twitter so let's start talking about security who a few likes to deal with security one two three four three and a half okay fill in a half it's not that pretty much so did I until a few years ago the reason was for me I didn't understand it then I checked the time and try to understand it read the specs and suddenly it made hey it's easy it's pretty easy but you have to have to take the time and understand how all this stuff really works and security is a wide range of topics and they're also the OVAs top ten which deal with the most most frequent security issues and but we don't want to talk about the top ten today we want to talk about often occasion and authorization so who a few things he or she knows what's a difference because between authorization and authentication okay bit more than Li half it's pretty easy I think but every time I'm talking to customers most of them don't get it right and it's easy as authentication is I don't know who you are please authenticate yourself tell me who you are and how can I make sure that you the person you tell me you are an authorization is the next step after I know who you are I have to check what are you allowed to do this is authorization and yeah also I mix it up still in my daily person is business when talking to customers sometimes I say authentication when I mean authorization and vice versa so if I mix it up today please don't be angry with me but also the HTTP status codes mix it up a bit and yes these are pretty old so the guys who made who who built up the status codes didn't get it either we have the four one which means which which is called unauthorized but it means unauthenticated or not authenticated for one is not really it does not deal with authorization it deals with authentication and once you are authenticated because status code four or three tells you you don't you are you're not allowed to do anything you're forbidden so for one unauthorized it's not it's not really correct so and we are in distributed api's nowadays the tributed systems the cpu today's api's at least we have single page application in the backend that's also a distributed system and how do we log in in such a system in a secure way and when talking when api's are talking to each other we how do they authenticate and authorize each other and when it comes oh yeah when we have distributed the api's or distribution systems should we have a centralized approach when it comes to authorization or authentication I think yes because it's called a single sign-on and single sign-on means there's only one system who knows my credentials and which knows how to verify these credentials and not two or three or more replicated systems with replicated data because then the the data the credential data of our users is replicated and many systems have haven't have a knowledge about this and we don't want to have many systems or most more than one system to have the knowledge how to verify the credentials only one system that's because it's it's called single sign-on single sign-on does not mean our users only have to login once when they come into the office in the morning and grab a coffee and they can work with FF system that's a side effect of single sign-on but not that's not the root of the word single sign-on the single is really the single system who knows about our credentials yeah and when it comes to to real users of course they want to have a simple and secure solution and you all know simply simple and secure these are two choose one you always have to choose what is more relevant for you has it to be more simple or has it beat or more secure the more secure the less simple it will be at least for you as a developer if you want to make it simple for therefore the users for the end users and secure for the data then the effort is at your side the developers site yeah how do you often ticket of course with our username email wherever a password a simple secret or temporary link or a mobile phone or whatever but then how do we transport these authentication infos to all the systems of course with the token and the token is nothing new already in the beginning of 2000's we have the the sam'l security assertion markup language which is pretty cool XML new XML and cool doesn't work doesn't fit together it's yeah it's powerful but it's kind of complex and it doesn't feel good and all these claims are difficult to handle and when we talk today about web applications and lightweight lightweight serialization and such things like Jason JavaScript it's really hard to handle XML with JavaScript I tried it once and I gave up after 2 days but the token itself is nothing really new and because sam'l isn't working pretty good with web technologies in nowadays there's the Hoth - framework or specification which deals with authorization or of - has nothing to do with authentication it just deals with authorization who is allowed to do what which system may access another system in your name of course you have to be authenticated before you can give another third party system the authority to access your own system but the authentication process is no standard way when using OAuth 2 or 2 is just authorization and the authentication process is completely different implemented when looking at the U of implementation of Twitter or Facebook or of github or whatever so you can use the login feature of Twitter or Facebook Google for your application but that's not really authentication that's only authorization you grant access to your application to access Twitter in your name when you're not in front of your computer and furthermore if you implement many of these providers you have to implement different ways of how to retrieve the user information the user profile information because every response from effort system looks different so although of to is just for authorization and not for authentication but is pretty powerful when it comes to web web applications or handling in the web and it has different so-called Krantz types or authorization flows they're the authorization code the standard flow which deals with many redirects between the systems and the browser and simple said the the user wants to access okay I can show you here an abstract protocol flow the user wants to access a secured resource on the resource server and the resource server says hey you're not authenticated please login or educate yourself and then I will see if you're allowed to do and redirects the user to login page of the authorization server and after the user locks in the authorization server sends back a an authorization code that's why it's called the authorization code flow and the authorization with the authorization code flow in the browser with a redirect to the application the client wants to access the application itself can crap the token from the authorization server and the token expresses what the user is allowed to do so with the token the resource server can deliver the protected resource to the client that's the most powerful ground-type or authorization flow authorization code and if you don't have the the ability to to take the authorization code flow and grab the token from the authorization server because that's you need you need an additional secret for the for the client fetching the the token at the authorization server and if you can't provide this secret for example in a public web site JavaScript side you need something other because yeah you can somehow encrypt or hash the secret but it's still in the in the front and the browser and the users device so the secret isn't a secret anymore and therefore you have the implicit flow and with the implicit flow you get implicit the token back to the response after the user locks in successfully if you don't have any chances or you don't want to have some redirects between systems and the users browser you can use the resource owner password credentials flow it sprite quite a nice resource only password credentials I have to read it every time and that's kind of an API sending the credentials directly to the authorization server and get back the token but this is the least least secure possibility because you as as the client application have you have to have the credentials in in your application to send it to the authorization server in the regular cases of authorization code or implicit flow the author's authorization server delivers the login page and the user enters his credentials directly at the other authorization server and with a resource on a path of potentials flow the user enters the credentials at your application and you take the application other credentials and send them to the authorization server so there are chances for men the middle attacks and when it comes to system system authorization there's the client credentials flow this is just for like it's like the idea of a relation code or the implicit flow but just for back-end applications there's no prouder involved and no redirects and lastly you have the Refresh token flow because every token has a special lifetime and after the token is invalid you have to renew refresh the jokin we can do this with the Refresh token flow and that's how the access token response looks like when your application gets the response from the token fetch or formulas reauthorization server you have the access token itself it can be Chester o pack string with no means for outside world the token type is Bearer it's always better when dealing with off - this is written in the spec as the s and expiry range it expires in 3600 seconds and we have the Refresh token with the Refresh token you can refresh in village access token so normally the access token has a very short lifetime between a few seconds and I say five minutes and the Refresh token has a long lifetime let's say half an hour an hour or whatever so this access token you can take this access token the string and to know what your user or your client is allowed to do you have to take this access token and ask the authorization server what is this user with this access token allowed to do and additionally you don't know who is this user you can only check what is this user allowed to do you don't know who is this user and this is where open ID connect games in open ID Connect is not open ID yet nothing has nothing to do with open ID it's just hosted by the Open ID Foundation which is also doing open ID and but it's called open that you connect and it's based technically it's based on all of - with the OAuth 2 flows and it standardizes profile user profile information and identity information so it brings in an identity token to the additionally to the access token we have an identity token and it adds user profile endpoint where you can grab identity information profile information of the user with his current access token and a few more restful endpoints for dealing with all this stuff so this is the identity token coming in into the response we have the access token the Refresh token know we have identity token but how does it look like how is the identity start into the token and this is where JSON web tokens come in JSON web token it's a standard since 2015 three years old and JSON web tokens are simply three concatenated base64 encoded strings so if the three strings mentioned in different colors and what it is like is that the header is payload and it's a signature and if you decode this can you read it here I think yes you see the header it just contains the type the jpg has the JWT has the type JWT okay and the algorithm with which the signature is signed or the signature is created then you have the payload for the payload you have a few reserved claims we can assume in the next slide the possible claims all the attributes are called claims in terms of JWT and the signature if it's a string concatenated of base64 encoded header and payload and depending on the the type of the algorithm used a synchronized algorithm the HS 256 with just a secret or you can use the hours to five six for a private public key usage so the token itself is so-called self-contained and you can always check if the token was changed by some third party when you get the token and so you have a certain kind of trust level when you get the token if the token itself is valid or it's not valid because only if you knew you even know the the secret when it comes to synchronized signature or you have to know the private key when dealing with public private public key encryption so you don't have to check the token at a another endpoint you can this can do this of course if you really need this kind of security but you don't have to use this endpoint yeah the payload itself it sets some reserved claims the subject issuer audition and expiry these are the only claims JWT claims for itself the subject is for for whom is the the token issued most of the time this is kind of a user ID the issuer is the issuing system represented as in URL the audition for which client application this token was issued for my API or for my shop or for whatever system and the expiry date and a suspect says jwg mustn't be used when the expiry date has expired so you have to check the signature of the signatures valid then you can use the token otherwise you must not use the soakin and it has to have a valid expiry date the rest of the payload you can choose freely whatever you want to put in the payload as you like almighty connect adds a more some more claim standard claims to the JWT token so if you use JWT in terms of all my ID connect you have to use these claims and I don't know it's difficult to read there was no other way to fit all the information to you to one slide it's but it's on a website of my D so we have claims for the name the given name the family knee and the middle name the nickname preferred username and so on also in the bottom you can see there's also address and address is not only string it's a JSON object so we have a nested object for the address information and the FS object itself is also specified so using JWT changes our access token response to look like this we have the access token the access token itself is when using almighty connect also expressed in JWT and if the token type the expires in when using JWT you don't need to use this expires in a tripod because the token itself has an expiry date and you have the identity token in a JWT format and the Refresh token also it doesn't make real sense to have the Refresh token as a JWT but yeah for simplicity reasons all tokens are JWT tokens the reach token itself contains just unique string for identifying this session on the authorization server okay and how can this tile can be used the user after of the successful authentication has a token he passes to the web application and the web application itself can pass the same token to back-end systems if this application needs to access third party or further back-end systems as we can see later in the demo it's also possible that the web application grabs an own so-called service account token for authentication authenticate authenticating itself against back-end systems or it can pass the the user token to the back-end systems so short conclusion for tokens a token assigned we have seen this and contains all necessary information about a user and its roles so in the access token all the roles the user has should be included we have different kinds of tokens with identity tokens refresh tokens access tokens and sometimes you have things like like an offline token and often in token you can a user can can request to have an offline token issued for another application and this and this other application can use this offline token for perhaps regular tasks at night when the user is not online creating reports or whatever sending emails to to exchange this offline token to well it access token and act in behalf of the user even if the user is not online but the user has to has to initiate the process for for creating an offline token so there's no global offline token as a system can use to act in behalf of a user the tokens are sent in bearer form are most often in the HTTP header authorization and we have a total time to live and of course tokens must be revocable I forgot this to mention an access token itself once it is issued it doesn't need to be verified at the authorization server I said before that's right because it's signed and it's self-contained so once it is issued it is well it and every system using it can be can be sure that it's valid but but what if the the token is stolen or whatever that's because the the access token should have a very very short total time to live I recommend most often between 30 seconds and 2 minutes because that's the time amount of time a third party can misuse this token if it gets the token and after this time you have to use the Refresh token and to refresh the excess toner get a new access token and if you have in the mean time the token the session revoked at the authorization server the server won't access in you exit wound oh no won't one create a new access token and and the third party can't use their token anymore so this must be revocable and as I'm a Chaba developer most of the times currently I'm dealing with the JavaScript I ask myself what does Chava offer to deal with oauth2 and Almighty connect and unfortunately it's not that much it's becoming better but it's very said the big Java EE standard now it's called Jakarta ee has a new security api jsrf tooth seven five which is quite nice this api but it doesn't deal with of - or almighty connect JWT there are some discussions on the mailing list and the issue list to integrate it or not and how to do it but for now there's nothing included and string security already made off to a first-class citizen in its implementation and before security 5 you had to use a third-party library to use OAuth 2 and open ID connect with spring security now it's included out of the box in spring security and there's some other libraries for example there's a patchy Shiro one of the well-known libraries dealing with security but also try ro doesn't have off to automatically connect JWT included there's some community efforts but nothing in the library itself but there's another library called Apache all to which does contain all the standards and my favorite questionnaire every conference who knows all to one ok yeah even me didn't know this library until I prepared the talk and how to look which libraries are out there dealing with both - and yeah it seems it's it's it's powerful library but nobody knows there are lots of more libraries available some dealing with orth - automatic connect some not and there of course a lot of libraries dealing with JWT looking at the ecosystem what's available for storing user data and providing all the flows and processes and points of course you can use of zero or HW s cognitive storm half some managed services providing all this functionality but you have to outsource you use this data of the current Angeles and that's I think most of the time not that's what you want to do to give other companies the credentials of users and besides other projects I liked you to use key clock from tables it's an open-source project it's not just a library it's a complete system providing all the services for Identity and Access Management and yeah in most of the cases it can be a good fit I also had some case the use cases at customers where I said ok key clock can do it but it's not the best fit for you needs take another solution but in the last few years most of the projects I did with my customers I introduced key clock to them and they're pretty happy so let's look into some demo how I did it first the architecture it's pretty simple I have a shop system as the the main system a user interacts with and stock service and the shipping service in the backend and the user gets user token passage to the shop and the shop itself gets an service account token issued for accessing the stock service because the stock service is also secured only allowed resources may access the the stock service and for calculating the shipping costs the the shipping service needs the user token so the shop pass the user token to the shipping service so this is key clock this is the year the admin interface and I have to I have created a shop client this is my shop application and the client protocol is open I do connect key talk also support summer but we don't want to deal with some over until only to deal with automatic connect and this is a confidential client which means this client has a secret for accessing the key clock server like a password for for the for the system itself and you can find it here it's the secrets generated and yeah we have a user user has user name user and this user has a roller called user very surprising and yeah we can now access our shop oh I have to start it first it's spring a spring boot application I will show you some some code a few minutes so we have the shop localhost no it's better it's my shop and come from Germany that's because the Euro symbol and I want to access a secured secured resource and the application redirects me to the key clock server to log in and all the things you can see on this page are coming with kiki look you don't have to implement them themselves the login process you have a register option you have forgotten password option you have Remember Me option you have the option to to use social login providers or you can come connect your your your LDAP or Active Directory to key cloak so that key cloak just does the authentication process but the credentials are stored in Active Directory and all this stuff you don't have to implement it yourself and then we can log in as a user and that's my cat shop you can buy cats you can see I'm the user and now I can put cats into the cart some double rounding feature we can see we have some stock information about the cats and the image service-based slow it's a public service with random pics and we have shipping costs of approximately a 10 euro and if I now look out and do some reconfiguration of my user ID ciao it's a wee up here I give the user just a simple attribute with a value true and now if login again and put cats into my cart you can see there are no shipping costs because if the user has we appear attribute there are no shipping costs used so that's the application itself let's look into the code how what I had to do to realize all this besides of the of the business logic for configuration of key clock for springboard application and spring Buddhism it's really simple but other java application service are quite similar we have to provide some configuration it's a realm it's called what Suresh make let's look yeah it's called walk sewage this is the real configure in key clock we have server URL it's localhost 8080 we have the the secret our resource is called shop we we saw this and in our principle attribute we want to have the preferred username claim that's one of the autumn ID Connect reserved claims and we use the servlet security specification to configure security collection which says all resources beneath the path shop should require a user role that's why we were redirected to the login page I didn't write a read wrote any code to redirect the user to the login page just this configuration leads to the login page of key club because the key clock adapter which is included in the application which is just a dependency in the palm have you keep log springboard starter and this dependency brings all the adapter logic to redirect to this server and if I authenticate myself come back to the application and the application fetches the access token from the key log server and knows I'm a valid user with a user role and leads me to the catalog which is done by the shop controller and when we have looked to the stocks get stocks method we have the sucks service get stocks and we use a rest template which I called key clock kind of rest template and I implemented myself it's just an extended standard rest template from spring and did some configuration magic there's the arrest template and make use of the earth client offset client this client comes where comes with key log adapters the dependency mentioned in the pom.xml and this client eases the process for authentication of educating the the the application itself against key clock to get a service account access token which is needed by the stock service and we can see the stock service the service itself needs the role stocks and as we can see it our user our user doesn't have the role stocks it's available but it's not assigned and our client shop there was a controls there it is has an assigned role stocks so the shop application itself verifies authenticates itself and key clock gets an access token and passes it to the start service and because the the token contains the stocks role it's allowed to access the stock service and we have the the shipping service at at last service this also needs the users role and key clock for votes the talk the user token to the the shipping service and in the shipping controller I can get I can access the key clock security context through the the request and in this context I can get a token or also I can get some identity token to get identity information or whatever I need and here I checked the the VIP claim just for completeness and the interesting part is and the shop application again shipping service I just use a regular rest template but I configured the rest template to use the key clock rest template customizer this also comes with key lock and the key clock rest template customizer is so I need to find it no that's just an interface the Interceptor yes the Interceptor and the Interceptor just cares about getting attributes from the request get the user principle and somewhere you know getting the key clock security context and putting the the token the token from the security context into the request to the shipping service to the backend so I didn't write any code to secure my applications just did configuration using the key clock application the key clock system server and can can make use of a highly secured application landscape so that's it time is over I hope you enjoyed the session and if you have any questions we have some four minutes left just ask your questions raise your hands or come in front of me yeah the code is not yet online but I can put it online later on and I will tweet the pass through repository so just follow me at does nico and it will be informed okay because but it's no real code it's just configuration the code is standard java spring boot code it's nothing there's no security code it's just configuration make use of the the key clock some key clock magic about the configuration of the rest templates but nothing more yeah okay that's one more did everybody understand the question or should I repeat it okay what's the what's the purpose of securing the boss back back-end systems the stock service and the shipping service because normally we should be in a controlled and secured area if it's really secured in this area most of the the attacks in systems came from internal net internal networks and even if you're in your own intranet controlled whatever at least the the administrator knows how to attack a system and you should secure all your systems regardless if the if their environment claims to be secure or not you should always use HTTPS you should always use authentication and authorization so we always can can check at the stock service when and how often the shop accessed the stock service so for auditing reasons or whatever you can you have the best basics in the second you propagate the user identity to the shipping service yes but this can be can be needed because somewhere piece don't have to pay shipping costs whatever yeah but this always also can be it can be a risk of propagating user identities to other systems so we have always deal with the pros and cons of your solution no system is perfectly secure he asked if I missed why I missed the the Scopes from off to and if it's a missing feature of key clock why I'm using roles and not scopes which which scopes exactly do you mean from fourth to okay okay it's just really a part of the specification or is this way of most companies do it okay key yeah Kiki clock first of all makes use of all mighty connect and JWT and mighty connect is based on all of - just for the the flows and because of mighty connect uses JWT and JWT can express all what you want you don't have to use some other possibilities scopes into additionally the two - JWT so we can put all the information you need in your token you don't have to use scopes from one technology from the earth to technology and use tokens from from almighty connect of course you can mix it if you want you can how are you you you put your your your authorization information into the token if it's roles or scopes it's completely up to you but Almighty connect is not with authorization it deals with authentication and in authentication you don't need roles or scopes it's just in addition to all this kind of stuff and yeah authorization with key clock can be a pain in my eyes for authentication it's pretty good authenticate an authorization can be really pain okay times over thank you all for listening and have a nice day [Applause]

Channel: freeCodeCamp.org

Views: 55,655

Keywords: sign in, Distributed systems, Microservices, web apis, single sign in, sso, oauth2, openid, jwt

Id: 0ndQbJaw89Y

Length: 53min 38sec (3218 seconds)

Published: Mon May 28 2018