securing your apis with oauth, openid, and openid connect

Securing your APIs with OAuth, OpenID, and OpenID Connect

Manish PanditSilicon Valley Code Camp 2015

About me

Manish PanditCapital One, San Francisco

@lobster1234

linkedin.com/in/mpandit

slideshare.net/lobster1234

7 years at #svcc

OAuthSocial Platforms

PlayFramework! Java – REST APIsMongoDB

Introducing ScalaPlayFramework! Scala – REST APIs

API Antipatters

APIsHave 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

API Security

ThrottlingDoS Protection

XSSInjections

Access ControlTransport Level Security

Identity

API Security

ThrottlingDoS Protection

XSSInjections

Access ControlTransport Level Security

Identity

Access Control

Who can get in

Whose data they can access

What can they access

For how long

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

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

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

Constraints

Fitness Site imports Nutrition site’s database nightly

Not real timeServer-to-server call

Needs to identify itself in order to access dataNutrition site may want to rate-limit it’s data access

There is no identity or user associated with the nutrition catalog

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

Constraints

Rewards site imports Fitness Site’s data nightly for all mutual users

Not real timeRewards site needs to identify mutual users

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

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

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.

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

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

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

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)

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)

Resource Owner

A user with data on a (Resource) server

(Steps on fitbit, Photos on Flickr, Status updates on Facebook, Tweets on Twitter)

Resource

Data on the Resource Server belonging to a user

(Fitbit steps, Flickr photos, Facebook updates, Twitter tweets)

Resource Server

The server that stores users’ data

(Fitbit, Flickr, Facebook, Twitter)

Authorization Server

The server that can assert users’ credentials

Usually same as the Resource Server (OpenID teaser!)

(Fitbit, Flickr, Facebook, Twitter)

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

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

Refresh Tokens

Used to re-request access_tokens

Have a very long expiration compared to access_tokens

Not bearer tokens

OAuth Credentials

client_id

client_secret

redirect_uri

These credentials are set up during client registration with the provider

OAuth Scopes

Defined by the API Provider

Can be cross cutting – Read/Write/Update/DeleteCan be grouped by feature – steps, rewardsCan be combined – Read steps, Write steps

OAuth Grants

Flows or Use Cases

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

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

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

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

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

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

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

Implicit GrantResource 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

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

OAuth and Identity

Blurry lines

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

OpenID and OAuth

OAuth is an authorization protocol

OpenID Connect is an authentication protocol built on OAuth (2.0)

OpenID 1.0 and 2.0

XML-based

Has a disconnect with API world

Low adoption

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

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

OpenID Connect Default Scopes

openid

profile

email

address

phone

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

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

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

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,}

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

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

Questions?

@lobster1234linkedin.com/in/mpandit