Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

API Security & Oauth Patterns RSA Europe @flascelles


Published on

Exposing service-oriented connectivity points using Web APIs, REST creates new security challenges for the enterprise. Mr. Lascelles’ presentation will make sense of SAML, OAuth, OpenID, API keys, HMAC, custom tokens, cookies and more, and will explain how these protocols fit together and how the enterprise can leverage such technologies for enabling trust management and access control.

Published in: Technology
  • Be the first to comment

API Security & Oauth Patterns RSA Europe @flascelles

  1. Enterprise Access Control Patterns for REST and Web API<br />Francois Lascelles<br />Layer 7 Technologies<br />Session ID: STAR-305<br />Session Classification: Intermediate<br />
  2. Today’s enterprise API drivers<br />SAAS<br />distributed enterprise SOA<br />Integration APIs!<br />partner<br />Cloud APIs!<br />IAAS/PAAS<br />B2B<br />APIs!<br />enterprise boundary <br />Access control?<br />B2C<br />APIs!<br /><ul><li>Sensitive data, apps
  3. Mission critical
  4. ID authority
  5. Legacy</li></ul>developer<br />mobile<br />
  6. Agenda<br />WS-* web services have rich security standards and authentication/authorization mechanisms<br />Web API, RESTful web services tend to use proprietary tokens, point-to-point solutions<br />What are the common patterns in use?<br />Which standards are emerging?<br />How to use specialized infrastructure to implement access control?<br />How to accommodate requesting party technical capabilities?<br />
  7. Pattern 1: API Keys in URI parameters<br />https://host/api/resource?keyid=foo&keysecret=bar<br />…<br />Simplest thing, common practice<br />Shared secret in a URL parameter based authentication, no signature involved<br />Equivalent to https://host/api/resource?username=franco&password=mysecret<br />Why not use HTTP Basic instead?<br />
  8. Pattern 2: HMAC<br />PUT /api/resource<br />…<br />Authorization: AWS keyid:fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=<br />…<br />Use the key to actually sign something<br />Shared secret not sent<br />Payload covered by signature -> message integrity<br />Timestamp covered by signature -> less susceptible to replay<br />Used by AWS, Azure<br />Implementations are proprietary, not compatible<br />5<br />
  9. Pattern 3: OAuth<br />Retrieve resource with owner authorization<br />(REST exchange)<br />Autz server<br />Application<br />Resource provider<br />Do something with my resource<br />Yes, I authorize it<br />Resource owner<br />GET /somewhere/someresource<br />…<br />Authorization: OAUTH fr0t5AzM6qT3S40pBPmfrTLJwMuZurA8=<br />…<br />
  10. OAuth Benefits<br />OAuth 2.0 is poised to fill the standards gap<br />Passwords remain secret<br />Tokens easier to ‘control’ than passwords<br />Resource-oriented => perfect for REST<br />Many different flows to accommodate different use cases (two and three parties)<br />Different token types<br />Bearer (easy, like cookies)<br />MAC (integrity, more secure)<br />
  11. What about SAML?<br />A rich and established standard for making various claims regarding an identity (authentication statements, authorizations statements, attribute statements)<br />SAML is well supported by existing enterprise infrastructure<br />SAML is verbose<br />8KB is too big a token for an authorization header or a query parameter<br />You can gzip + base 64 encode the token to make it fit<br />SAML is based on XML<br />My API uses JSON, not XML<br />It does not matter, the two should be decoupled<br />Binding specifications for Web browser SSO, SOAP+WSS, but no formal binding for REST, web APIs<br />SAML Bearer Profile for OAuth 2.0<br />
  12. Sample SAML binding for RESTful web service<br />GET /token/joe<br />Authorization: …<br />200 OK<br /><saml:Assertion …<br />/><br />GET /someresource<br />Authorization: SAML PmfrTLJwMuZurA8=<br />trust<br />200 OK<br />…<br />9<br />
  13. 10<br />Step-by-step enterprise API access control<br />(from an OAuth perspective)<br />
  14. Starting Point<br />enterprise/provider admin<br />Resources (API)<br />I need<br />more OAuth<br />FAIL!<br />OAuth Client<br />(application)<br />Resource owner<br />
  15. OAuth Clients Provisioning, Management<br />provider admin<br />app developer<br />2<br />1<br />OAuthClients<br />3<br />Create/manage my account, get shared secret, define my callback<br />Approve new clients, list existing client, get stats on usage<br />Provision app with account id, shared secret<br />
  16. Runtime Policy Modeling, Integration<br />1<br />OAuthClients<br />1<br />1<br />Prot Res Server<br />Administrator declares internal APIs to be accessed using OAuth authorization<br />which token types – Bearer, Mac<br />which flows<br /><br />
  17. OAuth Handshake<br />OAuthClients<br />OAuthTokens<br />2, 3<br />2, 3<br />2<br />3<br />OAuth Autz server<br />Prot Res Server<br />1<br />Client redirect owner to oauth provider<br />Policy looked up, flow executed: OAuth handshake as per flow. <br />Client is authenticated, gets access token<br />2<br />
  18. OAuth Resource Retrieval<br />OAuthClients<br />OAuthTokens<br />3<br />2<br />1<br />Prot Res Server<br />OAuth Autz server<br />Client uses access token to access resource<br />Protected resource server validates incoming token, authorize specific access based on token attributes, updates usage statistics<br />The API is called on behalf of, and returned to client<br />
  19. Token Refresh<br />OAuthClients<br />OAuthTokens<br />2<br />1<br />2<br />1<br />1<br />OAuth Autz server<br />Prot Res Server<br />2<br />Client uses refresh token to extend access resources on behalf of resource owner. Autz server authenticates Client and update the token<br />Client access resource using refreshed token<br />
  20. Owner-driven Token Revocation<br />OAuthClients<br />OAuthTokens<br />2<br />1<br />OAuth Autz server<br />Prot Res Server<br />2<br />FAIL!<br />Resource owner revokes authorization previously granted to Client. Autz server revokes corresponding token.<br />Client tries to access resource, access is refused.<br />1<br />
  21. Provider-driven Token Revocation<br />2<br />OAuthClients<br />OAuthTokens<br />3<br />OAuth Autz server<br />Prot Res Server<br />1<br />FAIL!<br />Client is hacked, access tokens compromised<br />Administrator revokes all tokens issued to this particular client<br />Hacker cannot use old tokens to access resources<br />3<br />Client prompts resource owner to repeat OAuth handshake. Owner does not need to change password.<br />
  22. Monitoring, Reporting<br />OAuthClients<br />OAuthTokens<br />OAuth Autz server<br />Prot Res Server<br />Analytics<br />Report on APIs, Clients, Owners. Monitor usage, performance.<br />
  23. Comprehensive REST Access Control<br />Omg, it’s full of win<br />OAuthClients<br />Provisioning<br />Approval Flow<br />Persistence<br />Querying<br />Metrics<br />OAuthTokens<br />Persistence<br />Querying<br />Metrics<br />Revocation<br />Refresh<br />*all of this*<br />OAuth Autz server<br />Policy Modeling<br />OAuth Protocol<br />Identity integration<br />Token issuing<br />Token refresh<br />SLA enforcement<br />Prot Res Server<br />Policy Modeling<br />Token validation<br />Bearer, MAC<br />Identity integration, SAML<br />Integrity check<br />API proxying<br />SLA enforcement<br />Analytics<br />Reports<br />Monitoring<br />SLAs<br />Alerting<br />
  24. APPLY<br />Decouple OAuth and other access control mechanisms from actual API implementations<br />Enable OAuth for existing APIs by deploying OAuth broker at perimeter<br />Configure, not code<br />Ensure support for OAuth 2.0 and all of its richness<br />21<br />
  25. 22<br />Thank you<br />For more information:<br /><br />