Making Sense of API Access Control
-
Upload
ca-api-management -
Category
Technology
-
view
2.899 -
download
6
description
Transcript of Making Sense of API Access Control
![Page 1: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/1.jpg)
Making Sense of API Access ControlOAuth, OpenID Connect and Token Mechanics
Francois LascellesChief Architect
![Page 2: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/2.jpg)
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
![Page 3: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/3.jpg)
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
![Page 4: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/4.jpg)
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
![Page 5: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/5.jpg)
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)
![Page 6: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/6.jpg)
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
![Page 7: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/7.jpg)
APIs and identity federation
![Page 8: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/8.jpg)
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>
![Page 9: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/9.jpg)
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
![Page 10: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/10.jpg)
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
![Page 11: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/11.jpg)
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
![Page 12: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/12.jpg)
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
![Page 13: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/13.jpg)
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
![Page 14: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/14.jpg)
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
![Page 15: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/15.jpg)
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
![Page 16: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/16.jpg)
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
![Page 17: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/17.jpg)
Token Mechanics
![Page 18: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/18.jpg)
Componentized OAuth provider
OAuth Authorization Server
OAuth Resource Server
Which subscriber?What is the scope?Which app?Still valid?Etc
abc123
abc123
![Page 19: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/19.jpg)
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
![Page 20: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/20.jpg)
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?
![Page 21: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/21.jpg)
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!
![Page 22: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/22.jpg)
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>
![Page 23: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/23.jpg)
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
![Page 24: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/24.jpg)
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
![Page 25: Making Sense of API Access Control](https://reader037.fdocuments.us/reader037/viewer/2022103115/5577cf24d8b42ae0418b4c9b/html5/thumbnails/25.jpg)
Thank you