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": janedoe@example.com, "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