• Share
  • Email
  • Embed
  • Like
  • Private Content
Making Sense of API Access Control
 

Making Sense of API Access Control

on

  • 2,612 views

Chief Architect Francois Lascelles presentation from Gluecon 2012. Are you ready to provide APIs that reach out to mobile applications, APIs that connect your applications to the cloud, APIs that ...

Chief Architect Francois Lascelles presentation from Gluecon 2012. Are you ready to provide APIs that reach out to mobile applications, APIs that connect your applications to the cloud, APIs that connect your applications with your business partners? Recent trends and standards are creating a new generation of API-focused identity patterns.

Learn how to:
• Apply API access control patterns with existing identity infrastructure
• Support emerging standards such as OAuth, Open ID Connect
• Empower developers to create APIs that reach out to your organisation’s target audience

Statistics

Views

Total Views
2,612
Views on SlideShare
1,939
Embed Views
673

Actions

Likes
3
Downloads
38
Comments
0

5 Embeds 673

http://www.layer7tech.com 659
http://www.layer7.com 6
http://layer7.com 4
http://www.twylah.com 2
http://translate.googleusercontent.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Making Sense of API Access Control Making Sense of API Access Control Presentation Transcript

    • Making Sense of API Access ControlOAuth, OpenID Connect and Token Mechanics Francois Lascelles Chief Architect
    • Making Sense of API Access Control Authentication HandshakeOAuth Token issuing Token verification API consumption Authorization Token revocation Token/session managementOpenID connect Token monitoring Federated identity
    • Anatomy of an OAuth handshake (one of many possible grant types illustrated) OAuth Authorization Server Subscriber(resource owner) consent 1 Authorization endpoint 1 +autz code 2 Token endpoint Application (client) +access token This is a shared secret
    • Why exchange a secret with an OAuth authorization server in the first place? OAuth Provider A: In order to consume an API OAuth Authorization Server Consume REST API OAuth Resource Server With access token from handshake API endpoint
    • Alternative handshakes (grant types) Authorization code (2 slides ago) Implicit +access token - Like autz code, but simpler - No code, just an access token Resource owner password credentials +access token - Client gets credentials from resource owner directly - No Redirection Client credentials +access token - Simple, two way handshake
    • Different handshakes, different situations Example: external/internal apps Provider Same API, different scopes Autz code Client creds Internal application not acting on behalf of a particular subscriber
    •  APIs and identity federation
    • Opaque / Interpreted tokens Opaque  Interpreted - Tiny - Medium to huge - Easy - For more „capable‟ relying parties - HTTPS based trust - Self contained trust - Callback issuer to get more info - Less dependent on server session <saml2:Assertion ...> <saml2:Issuer>francomacbook.l7tech.com</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <!--lots of fun stuff here --> </ds:Signature> <saml2:Subject> dBjfP[WHATEVER]OEjXk <!-- somwhere a subject name --> </saml2:Subject> <saml2:Conditions NotBefore="2007-12-11T12:23:00.000Z" NotOnOrAfter="2007-12- 11T12:45:28.529Z"></saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2007-12-11T12:25:28.527Z"> <!-- blah blah --> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="isStruggling" NameFormat="something"> <saml2:AttributeValue>yes</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion>
    • JSON Web Tokens (JWT)  JSON formatted token  Compact, API friendly  Claims – reserved, public, private  JWS signed and or JWE encrypted  No subject confirmation{"typ":"JWT", "alg":"HS256"} eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 .{ eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs "iss":"http:server.example.com", ZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwi "user_id":"248289761001”, b64urlencode YXVkIjoiaHR0cDpcL1wvY2xpZW50LmV4YW1wbG "aud":"http:client.example.com", UuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ "exp":1311281970 .} eDesUD0vzD…EPNXVtaazNQ JWS
    • Old-school identity federation – SAML Web browser SSO Great for sophisticated relying parties - Parse rich, verbose content SP - Cert based trust I trust what - Interpret SAML, SAML-P, XML dSig, … IdP says Common interop challenges - Subject confirmations - Key Reference, Sig Reference I assert to have authenticated I don‟t have a shared Usersecret with SP but I stillwant to create a session with it. SAML IdP redirect
    • Federation – Web Social Login Style User picks an identity broker (“NASCAR” login) OAuth 2.0 handshake - User authorizes SP to discover basic information about itself Web/Cloud/Mobile - Get an access token - Opaque, no complex interpretation needed SP discovers information about user - Using token issued to consume an API providing this information OAuth 2.0 + Fbook connect Example: Facebook connect
    • OpenID Connect: the love child of SAML and OAuth 2.0?XML, dsigVerbose OpenID ConnectIssues claims, statementsSubject confirmationsSAMLp SAML OAuth 2.0  What does it inherit from its mother? from its father?RESTfulHandshakes - Has endpointsEndpointsBearer, opaque tokens - Is API-friendly (REST)JSON - JSON - Issues token with claims (JWT) - Lots of specs
    • OpenID Connect Basic Client Profile OAuth handshake - Scope= openid [profile, email, address, phone] Two tokens - Access token - JWT id token, can be treated as opaque or not UserInfo Endpoint - Input: ID token - Output: get back back JSON-formatted identity CheckID Endpoint - Input: Access token, request additional attributes - Output: id attributes attributes
    • OpenID Connect Flows 1/2 OpenID Connect Provider OAuth 2.0 handshake, scope: openid HTTP/1.1 302 Found OAuth Authorization Server Location: https://client.example.com/cb# access_token=SlAV32hkKG&token_type=bearer &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu …ZXso&expires_in=3600&state=af0ifjsldkj id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0 { "iss": "https://server.example.com", CheckID Endpoint "user_id": "248289761001”, "aud": "s6BhdRkqt3”, "nonce": "n-0S6_WzA2Mj”, "exp": 1311281970, "iat": 1311280970, "at_hash": "ndrWKF5oXv8QulucTs1Bvg” } UserInfo Endpoint  Avoid decoding JWT, checking signature by relying party
    • OpenID Connect Flows 2/2  Discover additional information about OpenID Connect Provider end-user OAuth Authorization Server access_tokenRequestGET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: BearerSlAV32hkKG CheckID EndpointResponse{ "user_id": "248289761001”, "name": "Jane Doe”, "given_name": "Jane”, "family_name": "Doe”, "email": janedoe@example.com, "picture": "http://example.com/janedoe/me.jpg" UserInfo Endpoint}
    • When should you use OAuth only, with OpenID Connect? OAuth is used when an application needs to consume an API (sometimes on behalf of a user) OpenID Connect is used when an application wants to federate the authentication of and discover information about a user - Through API calls SP1 SP2 SP1 SP2 Subscribes to both providers, Subscribes to one provider, wants them to act on its behalf wants to use another
    •  Token Mechanics
    • Componentized OAuth provider OAuth Authorization Server abc123 abc123 OAuth Resource Server Which subscriber? What is the scope? Which app? Still valid? Etc
    • Token lifecycle Token Management - Facilitate token lifecycle (create, check, expire, revoke) - Store information associated to tokens - Preferably, an API Token Management OAuth Authorization Server Create new, refresh OAuth Resource Server Validate, query
    • Reusing tokens across APIs Token Management OAuth Authorization Server Create new, refresh OAuth Resource Server Validate, query API A ? ? OAuth Resource Server When is it ok to do this? API B
    • Managing and revoking tokens Challenge: enable the right parties to monitor and affect the right tokens - Multiple applications X multiple subscribers X multiple APIs API Based Token Management Look for unusual revoke usage Revoke! patterns Dev portal BI API Provider Subscriber portal FAIL! exploit compromise
    • Leverage existing SSO  API Management - Get SSO cookie, integrate with policy server (web agent) <handshake> - Associate SSO cookie with access token SSO token Check SSO session Maintain my SSO experience!  SSO Policy Server
    • Leverage existing identity attributes Authorization based on - Group memberships - Contract, plan, arbitrary attributes - Lookup directory, lookup database, lookup API  API Management - Lookup identity attributes - Check that requested scope should be <handshake> allowed - Remember attributes for later use My credentials ((cn=subcriber)(permission=foo))
    • Authorization checks, when?1. During original 2. At each refresh 3. At runtime handshake Days, hours, … Minutes, seconds, … Real time Token Management OAuth Resource Server Subscriber for token abc123?  Lookup scopeGet /different_resourceAccess Token = abc123  Lookup identity, attributes ((cn=subcriber)(newattribute=foo))  Lookup sso token  Lookup saml assertion  Lookup other associated token …
    •  Thank you