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.

1. Securing your APIs with OAuth,
OpenID, and OpenID Connect
Manish Pandit
Silicon Valley Code Camp 2015

2. About me
Manish Pandit
Capital One, San Francisco
@lobster1234
linkedin.com/in/mpandit
slideshare.net/lobster1234

3. 7 years at #svcc
OAuth
Social Platforms
PlayFramework! Java – REST APIs
MongoDB
Introducing Scala
PlayFramework! Scala – REST APIs
API Antipatters

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. API Security
Throttling
DoS Protection
XSS
Injections
Access Control
Transport Level Security
Identity

6. API Security
Throttling
DoS Protection
XSS
Injections
Access Control
Transport Level Security
Identity

7. Access Control
Who can get in
Whose data they can access
What can they access
For how long

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. 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. 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. 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. 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. Constraints
Rewards site imports Fitness Site’s data nightly for all mutual
users
Not real time
Rewards site needs to identify mutual users

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. 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. 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. 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. 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. 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. 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. 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. Resource Owner
A user with data on a (Resource) server
(Steps on fitbit, Photos on Flickr, Status updates on Facebook,
Tweets on Twitter)

23. Resource
Data on the Resource Server belonging to a user
(Fitbit steps, Flickr photos, Facebook updates, Twitter tweets)

24. Resource Server
The server that stores users’ data
(Fitbit, Flickr, Facebook, Twitter)

25. Authorization Server
The server that can assert users’ credentials
Usually same as the Resource Server (OpenID teaser!)
(Fitbit, Flickr, Facebook, Twitter)

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. 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. Refresh Tokens
Used to re-request access_tokens
Have a very long expiration compared to access_tokens
Not bearer tokens

29. OAuth Credentials
client_id
client_secret
redirect_uri
These credentials are set up during client registration with the
provider

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. OAuth Grants
Flows or Use Cases

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. 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. 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. 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. 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. 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. 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. 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. 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. OAuth and Identity
Blurry lines

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. OpenID and OAuth
OAuth is an authorization protocol
OpenID Connect is an authentication protocol built on OAuth
(2.0)

44. OpenID 1.0 and 2.0
XML-based
Has a disconnect with API world
Low adoption

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. 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. OpenID Connect Default Scopes
openid
profile
email
address
phone

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. 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. 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. 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. 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. 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. Questions?
@lobster1234
linkedin.com/in/mpandit