Rest API Security - A quick understanding of Rest API Security
2 likes1,408 views
This document discusses REST API security methods. It provides an overview of authentication and authorization and describes common security methods like cookie-based authentication, token-based authentication, OAuth, OpenID, and SAML. It then compares OAuth2, OpenID, and SAML and discusses best practices for securing REST APIs like protecting HTTP methods, validating URLs, using security headers, and encoding JSON input.
More Related Content
What's hot (20)
Similar to Rest API Security - A quick understanding of Rest API Security (20)
More from Mohammed Fazuluddin (20)
Recently uploaded (20)
Rest API Security - A quick understanding of Rest API Security
- 1. Rest API Security A Quick Introduction Of Rest API security Mohammed Fazuluddin
- 2. Topics Overview Rest API Security Methods Details Of Security Methods Comparisons Oauth2, OpenId and SAML Selection Of Rest API Security Method Best Practices To Secure REST API’S
- 3. Overview Authentication is common way to handle security for all applications. The basic keywords engaged in this process is “Authentication” and “Authorization”. Authentication can be defined as the process of verifying someone’s identity by using pre- required details (Commonly username and password). Authorization is the process of allowing an authenticated user to access a specified resource (Ex:- right to access a file). To secure the information which will be rendered in the client side then it should controlled be access the data with Authentication. Currently lot of websites has integrated with security systems to protect their data from the hackers and to protect the data they should access the Rest API’s securely.
- 4. Rest API Security Methods Following are the commonly used Rest API security methods which can be used to protect the Rest API access from the hackers. Cookie-Based authentication Token-Based authentication Third party access(OAuth, API-token) OpenId SAML
- 5. Details Of Security Methods Cookie based authentication: has been the default method for handling user authentication for a long time. The client posts the login credential to the server, server verifies the credential and creates session id which is stored in server(state-full) and returned to client via set-cookie. On subsequent request the session id from the cookie is verified in the server and the request get processed. Upon logout session id will be cleared from both client cookie and server.
- 6. Details Of Security Methods
- 7. Details Of Security Methods Token based authentication: single page applications(SPA) and statelessness(RESTful API’s)of the application. There are different ways to implement token based authentication, we will focusing on most commonly used JSON Web Token(JWT). On receiving the credentials from client the server validates the credentials and generates a signed JWT which contains the user information. Note, the token will never get stored in server(stateless). On subsequent request the token will be passed to server and gets verified(decoded) in the server. The token can be maintained at client side in local storage, session storage or even in cookies.
- 8. Details Of Security Methods
- 9. Details Of Security Methods Third party access(OAuth, API-token): if we have a need to expose our API’s outside of our system like third party app or even to access it from mobile apps we end up in two common ways to share the user information. Via API-token which is same as JWT token, where the token will be send via Authorization header which will get handled at API gateway to authenticate the user. The other option is via Open Authentication(OAuth),OAuth is a protocol that allows an application to authenticate against server as a user. The recommendation is to implement OAuth 1.0a or OAuth 2.0. OAuth 2.0 relies on HTTPS for security and it currently implemented by Google, Facebook, Twitter etc., OAuth 2 provides secured delegate access to a resource based on user..
- 10. Details Of Security Methods
- 11. Details Of Security Methods OpenId: is HTTP based protocol that uses identity provider to validate a user. The user password is secured with one identity provider, this allows other service providers a way to achieve Single SignOn(SSO) without requiring password from user. There are many OpenId enabled account on the internet and organizations such as Google, Facebook, Wordpress, Yahoo, PayPal etc., uses OpenId to authenticate users. The latest version of OpenId is OpenId Connect, which provides OpenId(authentication) on top of OAuth 2.0(authorization) for complete security solution.
- 12. Details Of Security Methods
- 13. Details Of Security Methods SAML: Security assertion markup language makes use of the same Identity provider which we saw in OpenId, but it is XML based and more flexible. The recommended version for SAML is 2.0. SAML also provides a way to achieve Single SignOn(SSO). User can make use of the Identity provider URL to login into the system which redirects with XML data back to your application page which can then be decoded to get the user information. We have SAML providers like G Suite, Office 365, OneLogin, Okta etc.,.
- 14. Details Of Security Methods
- 15. Comparisons Oauth2, OpenId and SAML
- 16. Selection Of Rest API Security Method If you have to support a web application only, either cookies or tokens are fine - for cookies think about XSRF, for JWT take care of XSS. If you have to support both a web application and a mobile client, go with an API that supports token-based authentication. If you are building APIs that communicate with each other, go with request signing.
- 17. Best Practices To Secure REST API’S Protect HTTP Methods: RESTful APIs often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record).Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. Protect HTTP Methods: It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity.For example, a GET request might read the entity, while PUT would update an existing entity, POST would create a new entity, and DELETE would delete an existing entity.
- 18. Best Practices To Secure REST API’S Protect Privileged Actions and Sensitive Resource Collections: The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use. Protect Against Cross-Site Request Forgery: For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross-Site Request Forgery. Typically, one would use a token-based approach. CSRF is easily achieved — even using random tokens — if any XSS exists within your application, so please make sure you understand how to prevent XSS.
- 19. Best Practices To Secure REST API’S URL Validations: Web applications/web services use input from HTTP requests (and occasionally files) to determine how to respond. Attackers can tamper with any part of an HTTP request, including the URL, query string, headers, cookies, form fields, and hidden fields, to try to bypass the site’s security mechanisms. XML Input Validation: XML-based services must ensure that they are protected against common XML-based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping, etc.
- 20. Best Practices To Secure REST API’S Security Headers: To make sure the content of a given resource is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and the Content-Type header should preferably include a charset. The server should also send an X-Content-Type-Options: nosniff to make sure the browser does not try to detect a different Content-Type than what is actually sent (as this can lead to XSS). JSON Encoding: A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using Node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.
- 21. THANKS If you feel that it is helpful and worthy to share with others then please like and share the same.