securing your apis with oauth, openid, and openid connect
Post on 15-Apr-2017
2.674 Views
Preview:
TRANSCRIPT
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
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
top related