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
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
Making Sense of API Access Control
1. Making Sense of API Access Control
OAuth, OpenID Connect and Token Mechanics
Francois Lascelles
Chief Architect
2. Making Sense of API Access Control
Authentication
Handshake
OAuth Token issuing
Token verification
API consumption
Authorization
Token revocation
Token/session management
OpenID connect
Token monitoring
Federated identity
3. 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
4. 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
5. 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
6. 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
8. 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>
9. 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
10. 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 User
secret with SP but I still
want to create a session
with it. SAML IdP
redirect
11. 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
12. OpenID Connect: the love child of SAML and OAuth 2.0?
XML, dsig
Verbose OpenID Connect
Issues claims, statements
Subject confirmations
SAMLp
SAML
OAuth 2.0
What does it inherit from its mother? from its father?
RESTful
Handshakes - Has endpoints
Endpoints
Bearer, opaque tokens - Is API-friendly (REST)
JSON
- JSON
- Issues token with claims (JWT)
- Lots of specs
13. 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
16. 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
18. Componentized OAuth provider
OAuth Authorization Server
abc123
abc123 OAuth Resource Server
Which subscriber?
What is the scope?
Which app?
Still valid?
Etc
19. 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
20. 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
21. 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
22. 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
23. 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))
24. 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 scope
Get /different_resource
Access Token = abc123 Lookup identity, attributes
((cn=subcriber)(newattribute=foo)) Lookup sso token
Lookup saml assertion
Lookup other associated token
…