Api security
- 1. API Security Teodor Cotruta 29 June 2016 Author of LDAP Client for Windows, LDAP 3.0 browser Programming in Java, OpenGL, C/C++, C#/.NET, VB, SQL, UNIX/Windows (20 years) Integration, SOA, REST/SOAP, Oracle fusion, IBM Crossworlds, Camel, JBoss esb Various websites: telecom.co.nz (8.5 years)
- 2. OS Hardware / Infrastructure API APIAPIAPI API API API API API Client/User Application Security Security User/*** Authentication Authorisation 1$/1hCompany Uni courses HTTP, TLS, OAuth, WRAP OpenID Connect, SAML Federation Delegation TOKEN, JSON, JWT, JWS, JWE
- 3. API = Application Programming Interface A set of functions, procedures and tools for building software and applications. Platform Hardware OS Protocols API Security Applications Client WEB 2.0 Cloud (AWS, Google, MS Azure) Web services, HTTP, HTTPS Web services SOA, SOAP, REST AAA, Federation Delegation Web applications Rich Internet Integration Users Business apps B2B PC, Laptops, Windows Windows API, .NET, Java Word, Excel, MSAccess, Oracle Users, Other apps PC, Sun stations, IPC V Unix, Linux Unix POSIX, Motif, Java Oracle Users Mobile Android Android OS Android API, Java, C Google app store, business app Users, applications, Surveys Macintosh EL Capitan Carbon, Cocoa IPhone Apple store Business apps
- 4. Managed and Naked APIs Managed API Naked API Can connect easily Intranet Security, documentation, life cycle, intelligence Manage load, Performance, access
- 5. Middleware ESB vs API Application API ESB Application API SOA APIAPI Proxy API Gateway SOA WS WS WS WS BUSINESS LOGIC 3. Name + Bank account FAST SECURE VISIBLE SLOW NOT ACCESSIBLE PARTIAL LOGIC 2. Account no 1. Name 4. Teo, 1234543
- 6. API = Application Programming Interface Twitter API Twitter Website
- 7. What is API Security? Security means Safe to do something at a certain location, during a specified period using some tools and information API Security means protecting the API against unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction. Protecting the applications and the users using the API.
- 8. WHEN TO implement security? https://msdn.microsoft.com/en-us/library/ms995349.aspx#sdl2_topic1_1 Microsoft SDL security dev lifecycle model - 2005 Security build should start along with API build.
- 9. HOW TO implement security? HTTP Authentication TLS – Transport Layer Security Identity delegation OAuth 1.0 OAuth 2.0 Federation, SAML and JWT (jot) OpenID Connect JWToken, JWSignature, JWEncryption Design Patterns and best practices
- 10. HTTP Basic Authentication HTTP Digest Authentication Sends credentials in cleartext over the wire A digest derived from the cleartext password is sent over the wire. Should be used in conjunction with some external security systems like TLS Doesn’t depend on transport-level security or external security systems. Only performs authentication Can be used to protect the integrity of the message, in addition to authentication User store can store passwords as a salted hash User store should store passwords in cleartext or should store a hash Basic authentication: Base64Encode (username:password) Digest authentication: Recommend to store hash (username:password:realm) HTTP Authentication
- 11. TLS = Transport Layer security One-way TLS, only the server proves its identity to the client; this is mostly used in e-commerce to win consumer confidence by guaranteeing the legitimacy of the e-commerce vendor. Two-way TLS Mutual authentication authenticates the client and the server. TLS Handshake process • 4 keys and a master secrete • Java key store • If one key leaks, we can get the master secret and all other 3 keys PFS Perfect forward secrecy enabled by Google in 2011 (gmail, search, google+) • Exchange data
- 12. Service to verify TLS sites Qualys SSL Labs https://www.ssllabs.com/ssltest/analyze.html free online service performs a deep analysis of the configuration of any SSL web server on the public Internet.
- 13. Identity Delegation Model 3 roles (actors) • delegator, owns the resource • delegate, wants to access the resource • service provider (resource server) hosts the protected service, validated the delegate Print app (delegate) Flickr Service Provider Grants privileges Imports photos Delegator Direct delegation File Editor Google drive Resource server Grants privileges Export filesGives read privilege On google drive Print app Read files Brokered delegation
- 14. Evolution of identity delegation Up to 2006 (give away username/password) • Sites were asking username/password on your email accounts to invite your friends, or SlideShare asked for your google username/password to use your google calendar. After 2006 • Google started using tokens
- 15. History after 2006 Google uses tokens Google AuthSub: App doesn’t know username/password Similar models were used by • Flickr Authentication API, before 2006 • Yahoo BBAuth similar to flicker WEB APP Google account Authentication Authorisation User Google services Request token Request access With token Response with Data Redirect to app With TOKEN Login page Access Y/N
- 16. History – Delegation models … + federation < 2006: Google AuthSub, Yahoo BBAuth, Flickr Authentication • 2007 OAUTH 1.0 – becomes standard Similar to Google, Yahoo and Flickr, request token, use token for data • 2009 OAUTH 2.0 As a result, OAuth 2.0 was developed as an authorization framework, rather than a standard protocol. OAuth 2.0 became RFC 6749 • 2009 OpenID/OAuth hybrid extension Integrate OAuth with OpenID, delegation with federation OpenId is a standard developed by the OpenId Foundation for decentralized single sign-on. http://openid.net/specs/openid-authentication-2_0.html. • OpenID Connect
- 17. OAUTH 1.0 = Open Authorization TOKEN A unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client. Tokens have a matching shared-secret that is used by the client to establish its ownership of the token, and its authority to represent the resource owner. 3 PHASES are defined in OAuth 1.0 handshake 1. Temporary-credential request phase 2. Resource-owner authorization phase 3. Token-credential request phase.
- 18. OAuth 1.0 Token dance Simplified 3 steps or phases 1. Credential request TOKEN + SECRET 2. Owner Authorisation: TOKEN + VERIFIER 3. Access token given: ACCESS TOKEN + SECRET CONSUMER APP AUTHORIZATION SERVER REQUEST TOKEN TOKEN Authenticates Authorises Token AUTHORISED REQUEST TOKEN PROTECTED API ACCESS TOKEN ACCESS TOKEN CREDENTIALAUTHORIZATONACCESS REQUEST ACCESS TOKEN TOKEN phases 1. TOKEN + SECRET credential 2. TOKEN + VERIFIER authorisation 3. ACCESS TOKEN + SECRET access
- 19. OAuth 1.0 = Credential + Authorisation + Access initial token, verified, new token • Temporary credential phase: TOKEN + TOKEN SECRET • Temporary-Credential Request Phase During the temporary-credential request phase, the OAuth client sends an HTTP POST to the temporary-credential request endpoint hosted in the resource server • At the end the client has oauth_token and an oauth_token_secret. • Resource-Owner Authorization Phase: TOKEN + VERIFIER • During the resource-owner authorization phase, the client must get the oauth_token received in the previous phase authorized by the user or the resource owner. The client redirects the user to the resource server with the following HTTP GET request. The oauth_token received in the previous phase is added as a query parameter. Once the request hits the resource server, the resource server knows the client corresponding to this token and displays it to the user on its login page. • The user must authenticate first and then authorize the token. • To initiate the resource-owner authorization phase, the client must have access to the oauth_token and the oauth_token_secret. At the end of this phase, the client has a new oauth_token and an oauth_verifier • Token-Credential Request Phase: NEW TOKEN (ACCESS) AND TOKEN SECRET • During the token-credential request phase, the client makes a direct HTTP POST or a GET request to the access-token endpoint hosted at the authorization server • To initiate the token-credential request phase, the client must have access to the oauth_token from the first phase and the oauth_verifier from the second phase. At the end of this phase, the client will have a new oauth_token and a new oauth_token_secret.
- 20. OAuth 2.0 Facebook, Google, Instagram, PayPal OAUTH 2.0: Facebook, Google, LinkedIn, Microsoft (MSN, Live), PayPal, Instagram OAUTH 1.0: Twitter WRAP uses the notion of profiles Client • The Client Account and Password Profile and • The Assertion Profile. User USER DELEGATION PROFILES • Username and Password Profile: installed trusted apps APP gets username/password, get a token, store the token for later use • Web App Profile: verification code then access token • Rich App Profile: installed app or mixed, mostly mobile Accessing a WRAP-Protected API curl –H "Authorization:WRAP access_token=cac93e1d29e45bf6d84073dbfb460" http://localhost:8080/recipe
- 21. OAuth 2.0 Oauth 2.0 adds two major extension points: • Grant types • Authorization code • Implicit • Resource owner password credential • Client credential • Token types A grant type defines how a client can obtain an authorization grant from a resource owner to access a resource on their behalf. The grant types in OAuth 2.0 are very similar to the OAuth profiles in WRAP { "access_token":"ya29.1.AADtN_WY1SHPAYomlwrc", "token_type":"Bearer", "expires_in":3600, "id_token":"" }
- 22. OAuth 1.0 vs. OAuth 2.0 OAuth 1.0 OAuth 2.0 Bearer Token Profile An access-delegation protocol An authorization framework for access delegation Signature based: HMAC- SHA256/RSA-SHA256 Non-signature-based, Bearer Token Profile Less extensibility Highly extensible via grant types and token types Less developer friendly More developer friendly TLS required only during the initial handshake Bearer Token Profile mandates using TLS during the entire flow Secret key never passed on the wire Secret key goes on the wire (Bearer Token Profile)
- 23. OAUTH 2 Profiles Built on top of OAUTH 2.0 grant types and token types • Token Introspection Profile • Chain Grant Type Profile • Dynamic Client Registration Profile • Token Revocation Profile EXAMPLES Salesforce revocation token • curl https://login.salesforce.com/services/oauth2/revoke? token='00D90000000…Teo4RMT' • anyone can revoke a token
- 24. Federation (Single Sign On, …) Federation, in the context of API security, is about Propagating user identities across • distinct identity-management systems or • distinct enterprises. Brokered Authentication • With brokered authentication, at the time of authentication, the authorization server can trust a broker from the given domain. • Each external party should have a trust broker whose responsibility is to authenticate its own users Uses OAuth principles, it means four entities in a federation scenario: • Owner for resource • Server with resource • Authorization server • Client application
- 25. Brokered authentication OAuth Client app YAHOO XTRA WEB MAIL Client ID OAuth Authorisation Server Authorization code Trust Broker authenticate Signed assertion Redirects user Client id + Signed assertion OWNER EMAIL API (SERVER) WEB MAIL Client Trust Broker UK ACCESS TOKEN Get email 1 Yahoo website (SERVER) 2 34 ACCESS TOKEN 1. OWNER Request 2. Redirect Auth code 3. Authenticate Assertion 4. Authorise Access Token Get Email
- 26. SAML (XML), JWT (JSON) SAML: Security Assertion Markup Language Standard for exchanging authentication, authorization, and identity- related data between interested parties in an XML-based data format Assertions, Protocol (SAML Request/Response), Bindings Profiles: Web Single Sign-on profile defines a standard way to establish SSO between different service providers via SAML. JSON Web Token (JWT) is a well-structured JSON message. Both profiles address the same use cases.
- 27. OpenID Connect = OpenID + OAuth 2.0 • Identity layer built on top of OAuth 2.0 • OpenID Connect: standard February 26, 2014. • Lightweight framework for identity interactions using REST • OpenID extension for OAuth 1.0 OpenID + OAuth 1.0 = authentication + delegated authorisation • OpenID Connect The ID token is the primary add-on to OAuth 2.0 to support OpenID Connect
- 28. OpenID protocol flow Relying party OpenID || OpenID Provider OpenID Provider OpenID protocol scenario 1. Enter OpenID on the relying party site 2. Discover the OpenID provider, if not known 3. Shared secret key between the RP and OP 4. User redirected to OpenID provider 5. User has to authenticate 6. Relying party receives a response 7. Relying party checks the response signature Which should be signed with the secret key Exchanges between relying party And the provider including authentication Of the use on the provider
- 29. OpenID Connect OpenID Connect Relying party OpenID Provider User identifier ID Token
- 30. JWT JWS JWE JASON Web token • JSON Web Token (JWT) defines a container to transport data between interested parties in JSON • The OpenID Connect specification, uses a JWT to represent the ID token. • Google API is one example JSON Web Signature • The JSON Web Signature (JWS) specification, developed under the IETF JOSE working group, defines how JSON messages can be digitally signed or MACed JSON Web Encryption • The JSON Web Encryption (JWE) specification, defines how JSON messages can be encrypted. • It introduces two new attributes (enc and zip) to be included in the JWE header of an encrypted JSON payload First signed, then encrypted
- 31. Patterns and practices Direct Authentication with the Trusted Subsystem Pattern WEB APP API available LDAP Federation Single Sign on Pattern Token dance, OAuth 1.0
- 32. Risks and vulnerabilities OWASP Open Web Application Security Project (OWASP) There are scanners for • Injection • Broken Authentication and Session Management • Cross Site Scripting • Insecure Direct Object References • Security Misconfiguration • Sensitive Data Exposure • Missing Function Level Access Control • Cross Site Request Forgery • Using Components with Known Vulnerabilities • Invalidated Redirects and Forwards. http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf
- 34. Case studies with examples Sample Methods in time What has been used Pro Cons Large website in NZ Start with requirements Security available off the self Siteminder Sun IDA Availability of a known product Documentation Team skills ok Training available Hard to maintain (special team) High coupling between code and security, impossible to change in the future Desktop software distribution After the fact Custom made License model Protects revenue Unflexible Difficult to move from a machine to another Desktop software distribution Off the self product License model Protect revenue Easy to use Known issues, vulnerable to attacks. Web applications In house during development OAUTH 1.0 Can change at will Doesn’t cover all scenarios, requires patches Web applications Third party products Hard to implement No experience Industry standards In house build None Hard to implement No experience
- 35. CONCLUSION API Security API meaning has changed in the past decade, meaning apps that are used on the internet. This can be achieved through SOA, especially REST and JSON. Security evolved with a number of models, the most important being: • OpenID Connect • JWToken, JWSignature, JWEncryption • Federation, SAML and JWT (jot) • Identity delegation • OAuth 2.0 quite equal with OAuth 1.0 • TLS – Transport Layer Security • HTTP Authentication
- 36. OS Hardware / Infrastructure API APIAPIAPI API API API API API Client/User Application Security Security User/*** Authentication Authorisation 1$/1hCompany Uni courses HTTP, TLS, OAuth, WRAP OpenID Connect, SAML Federation Delegation TOKEN, JSON, JWT, JWS, JWE
- 37. Bibliography 1. Advanced API Security, Prabath Siriwardena, apress, 2014 2. OpenID connect: http://openid.net/connect/ 3. Securing the API Stronghold, Travis Spencer and all, nordicaps.com, 2015, http://nordicapis.com/wp-content/uploads/securing-the-api-stronghold.pdf 4. How to control User Identity within microservices http://nordicapis.com/how-to-control-user-identity-within-microservices/ 5. Rest security cheat sheet https://www.owasp.org/index.php/REST_Security_Cheat_Sheet 6. State of API security https://www.soapui.org/testing-dojo/world-of-api-testing/state-of-api- security.html