making sense of api access control
DESCRIPTION
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 audienceTRANSCRIPT
Making Sense of API Access ControlOAuth, OpenID Connect and Token Mechanics
Francois LascellesChief Architect
Making Sense of API Access Control
Handshake
API consumption
Token/session management
Federated identity
OpenID connect
Authentication
OAuth Token issuing
Token verification
Authorization
Token revocation
Token monitoring
Anatomy of an OAuth handshake
Subscriber(resource owner)
OAuth Authorization Server
+access token
+autz code
This is a shared secret
Authorization endpoint
Token endpoint
Application(client)
1
1
2
redire
ct
redirect
(one of many possible grant types illustrated)
consent
Why exchange a secret with an OAuth authorization server in the first place?
A: In order to consume an APIOAuth Provider
OAuth Authorization Server
OAuth Resource ServerConsume REST API
With access token from handshake
API endpoint
Alternative handshakes (grant types)
Authorization code
Implicit
- Like autz code, but simpler
- No code, just an access token
Resource owner password credentials
- Client gets credentials from resource owner directly
- No Redirection
Client credentials
- Simple, two way handshake
+access token
+access token
+access token
(2 slides ago)
Different handshakes, different situations
Example: external/internal apps
Autz code
Client creds
Internal application not acting on behalf of a particular subscriber
Same API, different scopes
Provider
APIs and identity federation
Opaque / Interpreted tokens
Opaque
- Tiny
- Easy
- HTTPS based trust
- Callback issuer to get more info
Interpreted
- Medium to huge
- For more ‘capable’ relying parties
- Self contained trust
- Less dependent on server session
dBjfP[WHATEVER]OEjXk
<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> <!-- 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
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJ1c2VyX2lkIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiaHR0cDpcL1wvY2xpZW50LmV4YW1wbGUuY29tIiwiZXhwIjoxMzExMjgxOTcwfQ.eDesUD0vzD…EPNXVtaazNQ
{"typ":"JWT", "alg":"HS256"}
{ "iss":"http:\\server.example.com", "user_id":"248289761001”, "aud":"http:\\client.example.com", "exp":1311281970}
b64urlencode
JWS
Old-school identity federation – SAML Web browser SSO
Great for sophisticated relying parties
- Parse rich, verbose content
- Cert based trust
- Interpret SAML, SAML-P, XML dSig, …
Common interop challenges
- Subject confirmations
- Key Reference, Sig Reference
SAML IdPredirect
redi
rect
SP
I don’t have a shared secret with SP but I still want to create a session
with it.
I trust what IdP says
I assert to have authenticated
User
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
- Get an access token
- Opaque, no complex interpretation needed
SP discovers information about user
- Using token issued to consume an API providing this information
Web/Cloud/Mobile
OAuth 2.0+
Fbook connect
Example: Facebook connect
OpenID Connect: the love child of SAML and OAuth 2.0?
What does it inherit from its mother? from its father?
- Has endpoints
- Is API-friendly (REST)
- JSON
- Issues token with claims (JWT)
- Lots of specs
SAML
OAuth 2.0
OpenID ConnectXML, dsigVerboseIssues claims, statementsSubject confirmationsSAMLp
RESTfulHandshakesEndpointsBearer, opaque tokensJSON
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 Authorization Server
CheckID Endpoint
UserInfo Endpoint
OAuth 2.0 handshake, scope: openid
HTTP/1.1 302 FoundLocation: https://client.example.com/cb#
access_token=SlAV32hkKG&token_type=bearer&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu …ZXso&expires_in=3600&state=af0ifjsldkj
{ "iss": "https://server.example.com", "user_id": "248289761001”,"aud": "s6BhdRkqt3”,"nonce": "n-0S6_WzA2Mj”,"exp": 1311281970,"iat": 1311280970,"at_hash": "ndrWKF5oXv8QulucTs1Bvg” }
Avoid decoding JWT, checking signature by relying party
id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0
OpenID Connect Flows 2/2
OpenID Connect Provider
OAuth Authorization Server
CheckID Endpoint
UserInfo Endpoint
RequestGET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG
Response{ "user_id": "248289761001”, "name": "Jane Doe”, "given_name": "Jane”, "family_name": "Doe”, "email": [email protected], "picture": "http://example.com/janedoe/me.jpg" }
Discover additional information about end-user
access_token
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 one provider, wants to use another
Subscribes to both providers, wants them to act on its behalf
Token Mechanics
Componentized OAuth provider
OAuth Authorization Server
OAuth Resource Server
Which subscriber?What is the scope?Which app?Still valid?Etc
abc123
abc123
Token lifecycle
OAuth Authorization Server
OAuth Resource Server
Token Management
Create new, refresh
Validate, query
Token Management
- Facilitate token lifecycle (create, check, expire, revoke)
- Store information associated to tokens
- Preferably, an API
Reusing tokens across APIs
OAuth Authorization Server
OAuth Resource Server
API A
Token Management
Create new, refresh
Validate, query
OAuth Resource Server
API B
?
?
When is it ok to do this?
Managing and revoking tokens
Challenge: enable the right parties to monitor and affect the right tokens
- Multiple applications X multiple subscribers X multiple APIs
compromise
Dev portal
Subscriber portal
exploit
revoke
API Provider
Look for unusual usage
patterns
BI
API Based Token Management
Revoke!
FAIL!
Leverage existing SSO
SSO Policy Server
API Management
- Get SSO cookie, integrate with policy server (web agent)
- Associate SSO cookie with access token
SSO token
Check SSO session
Maintain my SSO experience!
<handshake>
Leverage existing identity attributes
API Management
- Lookup identity attributes
- Check that requested scope should be allowed
- Remember attributes for later use
((cn=subcriber)(permission=foo))
<handshake>
Authorization based on
- Group memberships
- Contract, plan, arbitrary attributes
- Lookup directory, lookup database, lookup API
My credentials
Authorization checks, when?
((cn=subcriber)(newattribute=foo))
Get /different_resourceAccess Token = abc123
OAuth Resource Server
Token Management
Subscriber for token abc123?
Lookup scope
Lookup identity, attributes
Lookup sso token
Lookup saml assertion
Lookup other associated token
…
1. During original handshake
2. At each refresh 3. At runtime
Days, hours, … Minutes, seconds, … Real time
Thank you