Securing your APIs with OAuth, OpenID, and OpenID Connect

2,209 views

Published on

As products and companies move towards IoT model, users and machines alike need to interact with various APIs. Securing these APIs in a connected world can be a challenge faced by many. Fortunately, there are open standards addressing even the most complex of use cases - OAuth, OpenID and OpenID Connect happen to be widely adopted and have a growing support across many API and Identity Providers. In this session I'll talk about these standards, and walk through common use cases/flows from an API Provider as well as consumer's side. We will explore how these standards come together to not only secure the APIs, but also manage identity.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,209
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
37
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Securing your APIs with OAuth, OpenID, and OpenID Connect

  1. 1. Securing your APIs with OAuth, OpenID, and OpenID Connect Manish Pandit Silicon Valley Code Camp 2015
  2. 2. About me Manish Pandit Capital One, San Francisco @lobster1234 linkedin.com/in/mpandit slideshare.net/lobster1234
  3. 3. 7 years at #svcc OAuth Social Platforms PlayFramework! Java – REST APIs MongoDB Introducing Scala PlayFramework! Scala – REST APIs API Antipatters
  4. 4. APIs Have always been around Medium of information exchange RESTful, SOAP, Custom May carry sensitive data over the wire Can be called on behalf of a user
  5. 5. API Security Throttling DoS Protection XSS Injections Access Control Transport Level Security Identity
  6. 6. API Security Throttling DoS Protection XSS Injections Access Control Transport Level Security Identity
  7. 7. Access Control Who can get in Whose data they can access What can they access For how long
  8. 8. Typical Scenario Online photo sharing website Allows users to upload pictures The pictures can be flagged as private, or public Users log in to the website using userId/password The users want to import these pictures into their Facebook
  9. 9. IoT – More players Fitness site tracks the number of steps you take The site also allows you to track your calories via a food log Fitness site uses a Nutrition website to get calorie counts The user can share his steps on a Rewards site, which rewards the user based on the steps. Rewards site does not care about his food intake
  10. 10. Old Fashioned Way Fitness Site imports Nutrition site’s database nightly Rewards site stores the users’ credentials for Fitness Site in it’s database to access their data Rewards site imports Fitness Site’s data nightly for all mutual users
  11. 11. Constraints Fitness Site imports Nutrition site’s database nightly Not real time Server-to-server call Needs to identify itself in order to access data Nutrition site may want to rate-limit it’s data access There is no identity or user associated with the nutrition catalog
  12. 12. Constraints Rewards site stores the users’ credentials for Fitness Site in it’s database to access their data Rewards site can use the Fitness Site’s credentials to access any data it wants on the users’ behalf In the event of Rewards site getting compromised, the users of Fitness site risk their credentials leaked Other than the credentials, the Rewards site does not know the identity of the user
  13. 13. Constraints Rewards site imports Fitness Site’s data nightly for all mutual users Not real time Rewards site needs to identify mutual users
  14. 14. Access Patterns Have the Fitness site identify itself to the Nutrition site Have the Rewards site identify itself to the Fitness site Have the Rewards site users identify themselves to the Fitness site Have these users grant or deny access to finer grained data after authentication
  15. 15. Delegated Authentication A (much!) safer alternative to storing user/password for another site in your database Authenticate the user on the site that has both, his identity and his data Multiple identities – One on Rewards site, Another on Fitness site
  16. 16. Delegated Authentication Authorize a service to finer grained data The Fitness site user can choose to grant access to his steps to the Rewards site, not his food log.
  17. 17. Challenges Authentication at the source of Identity Multiple User Identities Multiple application or website identities Authorization, or limiting the data access at the users’ will
  18. 18. Decomposition - Authentication User has credentials for the Fitness website User has separate credentials for the Rewards site User has no idea about the Nutrition site, but the Fitness site does
  19. 19. Decomposition - Authorization User can only access his data on the Fitness site Fitness site can access entire Nutrition Catalog from the Nutrition site Rewards site can only access steps for a user on the Fitness site, and not his food log
  20. 20. Decomposition - Identity Fitness Site is an identity provider (for users) Rewards site is an identity provider (for users) Nutrition site is an identity provider (for other sites that pull its catalog)
  21. 21. OAuth A protocol to allow for Authenticating the sites requesting data Delegating user’s authentication to the identity provider Followed by subsequent authorization Relies on transport layer security for on-wire (2.0)
  22. 22. Resource Owner A user with data on a (Resource) server (Steps on fitbit, Photos on Flickr, Status updates on Facebook, Tweets on Twitter)
  23. 23. Resource Data on the Resource Server belonging to a user (Fitbit steps, Flickr photos, Facebook updates, Twitter tweets)
  24. 24. Resource Server The server that stores users’ data (Fitbit, Flickr, Facebook, Twitter)
  25. 25. Authorization Server The server that can assert users’ credentials Usually same as the Resource Server (OpenID teaser!) (Fitbit, Flickr, Facebook, Twitter)
  26. 26. Client Any application* trying to access resources on the resource server on a resource owner’s behalf (Fitbit, Flickr, Facebook, Twitter) * A client can be a resource server of its own, and vice versa
  27. 27. Access Tokens A proxy artifact for user credentials Bearer tokens A result of an authorization step access_tokens allow clients to access a resource owner’s data access_tokens expire after a period of time access_tokens can be re-issued
  28. 28. Refresh Tokens Used to re-request access_tokens Have a very long expiration compared to access_tokens Not bearer tokens
  29. 29. OAuth Credentials client_id client_secret redirect_uri These credentials are set up during client registration with the provider
  30. 30. OAuth Scopes Defined by the API Provider Can be cross cutting – Read/Write/Update/Delete Can be grouped by feature – steps, rewards Can be combined – Read steps, Write steps
  31. 31. OAuth Grants Flows or Use Cases
  32. 32. Client Credentials Grant Solves for the server-to-server calls https://api.example.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
  33. 33. Client Credentials Grant No redirect_uri No selective granting of scopes There is no resource owner, or identity involved Simple flow, used for server to server calls via shared credentials Also known as 2-legged OAuth
  34. 34. Password Grant Client credentials and resource owner credentials are used together to get access token https://api.example.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID
  35. 35. Password Grant Used for trusted, native mobile apps No redirect_uri No selective granting of scopes The resource owners’ credentials are captured by the client The container (app) should be guaranteed to be secure in order to store resource owner credentials
  36. 36. Authorization Code Grant Delegated authentication – the resource owner is redirected to the identity/resource server for authorization, followed by token exchange https://api.example.com/token? grant_type=authorization_code& code=AUTH_CODE_HERE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET
  37. 37. Authorization Code Grant Resource Owner is sent to an authorization_url with client_id and redirect_uri Resource owner logs into the Resource Server Resource owner authorizes the client by granting access Resource Server calls back the client on a redirect_uri with a code The client exchanges this code for an access_token and a refresh_token using the client_id and client_secret
  38. 38. Authorization Code Grant A true, delegated authentication Client and Resource Owner credentials are asserted separately Client has to be a server or service (not browser) Also called 3-legged Oauth Always has a UX
  39. 39. Implicit Grant Resource Owner is sent to an authorization_url with client_id and redirect_uri The client is a browser or mobile, so no client_secret. The callback_uri is a javascript callback Not a 2-step process like Authorization Code Lesser used grant
  40. 40. Authorization Code Grant Resource Owner is sent to an authorization_url with client_id Resource owner logs into the Resource Server Resource owner authorizes the client by granting access Resource Server calls back on the redirect_uri with access_token as a hash URL parameter
  41. 41. OAuth and Identity Blurry lines
  42. 42. OpenID A way to consolidate identity by having portable identities Authentication Protocol Large identity providers, eliminating a need for websites to have their own identity stores
  43. 43. OpenID and OAuth OAuth is an authorization protocol OpenID Connect is an authentication protocol built on OAuth (2.0)
  44. 44. OpenID 1.0 and 2.0 XML-based Has a disconnect with API world Low adoption
  45. 45. OpenID Connect Third revision of OpenID Based on OAuth 2.0 Much wider adoption JSON Based Interoperable with APIs OAuth 2.0 + Identity = OpenID Connect
  46. 46. OpenID Connect Identity as an Oauth 2.0 scope Allows for finer grained access to user attributes (claims) Provides an endpoint to get those attributes Relies on JWS (JSON Web Signature) for crypto Relies on JWT (JSON Web Token) to represent claims
  47. 47. OpenID Connect Default Scopes openid profile email address phone
  48. 48. OpenID Connect Claims Claims are finer grained attributes within the scopes They can be individually access-controlled during the authentication process email scope – email, email_verified profile scope – name, family name, given name, gender
  49. 49. OpenID Connect Parties RP or Relying Party is the one which is requesting identity IDP or Identity Provider is the one which is asserting identity
  50. 50. OIDC Response Returned after authentication step JWT standard (JSON Web Token) Contains metadata like issue date, expiration, nonce along side id_token Can be encrypted via JWS (JSON Web Signature) Also contains an access_token that can be used for calling userinfo
  51. 51. A JWT { "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" "access_token": ”some_token", "token_type": "Bearer", "expires_in": 3600, }
  52. 52. userinfo A userinfo endpoint is accessed via an OIDC access token that is returned as a result of authentication This call returns the claims from the user’s profile that the user has consented to
  53. 53. OAuth and OpenID Connect The authorization URL is configured as a RP to an OIDC compliant IDP The user authenticates, resulting in a JWT with id_token and an access_token The JWT is exchanged for an access_token or a authorization code based on the oauth grant The access_token can be then used to invoke /userinfo when needed
  54. 54. Questions? @lobster1234 linkedin.com/in/mpandit

×