Making Sense of API Access Control

Making Sense of API Access Control
OAuth, OpenID Connect and Token Mechanics

Francois Lascelles
Chief Architect

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

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

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#">

</ds:Signature>
<saml2:Subject>
dBjfP[WHATEVER]OEjXk 
</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">

</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 User
secret with SP but I still
want 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, 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

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


access_token

Request
GET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: Bearer
SlAV32hkKG

CheckID Endpoint
Response
{
"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

Componentized OAuth provider

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

?

?
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

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
…

Making Sense of API Access Control

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Making Sense of API Access Control

Similar to Making Sense of API Access Control (20)

More from CA API Management

More from CA API Management (20)

Recently uploaded

Recently uploaded (20)

Making Sense of API Access Control