Who’s Knocking? Identity for APIs, Web and Mobile

Copyright ©2012 Ping Identity Corporation. All rights reserved. 1

Who’s Knocking?

Identity for APIs, Web and Mobile

Hans Zandbelt - @hanszandbelt

CTO Office - Ping Identity


Overview

Cloud & APIs: The Trends

- History, state-of-the-art, trends

Identity and APIs

- What, why, how

Recommendations

- API strategy

1

2

4

OAuth 2.0

- Not for Authentication!

3


CLOUD & APIS: THE TRENDS

[section lead-in]


Cloud/Mobile Moves: 3 Dimensions of Change

• Users

– Workforce

– Customers/consu

mers

– Partners

– Social

• Devices

– Mobile/fixed

– Browser/app

– BYOD/E-owned

• Location

– Services

– Users

Users

Location(s)

Devices


Traditional firewall and enterprise domain-based security cannot deal with Cloud Apps and Mobile

devices and applications.

IDENTITY IS THE NEW PERIMETER

Consequences

FIREWALL


How it could/should be: Cloud 2.0 (web or mobile)

firewall

APP

APP

database

directory

SaaS

SaaS

SaaS

database


The API Economy Drivers

• SaaS

– API access to

data/services vs.

browser access

– Cloud, Mobile/Big

Data, BYOD

– Salesforce.com >

60%

• APIs of PaaS

offerings

– Expose own cloud

services

• Clear trend for APIs

towards REST


IDENTITY & APIS


The Internet Scale Identity Concept

• Identity Provider

– Authoritative

– Scale

– Manageability

• UNIFORM across

Web SSO & API

Access

• Security AND

Convenience

• How to extend

enterprise security

policies to the cloud:

a MUST have

verify


Web SSO and API Access Playfield

User Provisioning

Web SSO API Access


API Access

• HTTP

• SOAP

– WS-Security/WS-

Trust

• REST

– ?

• TOKEN

– Obtain

– Use

– Validate

• Passwords?? CLIENT

SERVICE

SOAP / REST

Token


Password anti-pattern

• 3rd party client

store user

passwords

• Teaches users to

be indiscriminate

with passwords

• No multi-factor or

federated

authentication

• No granularity

• No differentiation

• No revocation


Drivers

Lack

Of

Standards

Password

Anti

Pattern

Native

Mobile

Apps

REST

Cloud

APIs


OAUTH 2.0


OAuth 2.0

• Secure API

authorization

– simple & standard

– desktop, mobile web

• Auth & Authz for

RESTful APIs

• Delegated

authorization

– mitigates password

anti-pattern

• Issue tokens for

granular access

– Without divulging

your credentials


OAuth 2.0 Terminology: Roles

• Authorization Server (AS)

A server capable of issuing

tokens, obtaining authorization,

and authenticating resource

owners.

• Resource Owner

An entity (usually an end-

user/person) capable of granting

access to a protected resource.

• Client

An application(!) obtaining

authorization and making

protected resource requests (on

behalf of the resource owner).

• Resource Server (RS)

The server hosting protected

resources.

verify


A. Client sends Authorization Request

"GET /as/authorization.oauth2?client_id=TunesPartner-OT&state=TunesPartner-OT&response_type=code&scope=onetime-a HTTP/1.1” 302 0

B. Service Provider grants Authorization

https://www.tunespartner.com:9031/Partner/callback.jsp?state=TunesPartner-OT&code=IEM_peySP5KvIfVs8fT650FxbgXwjdqN8tHXdyh7

C. Client Request Access Token

POST https://idp.idtel.com:9031/as/token.oauth2

---PARAMETERS---

client_id: TunesPartner-OT&

grant_type: authorization_code&

Code: IEM_peySP5KvIfVs8fT650FxbgXwjdqN8tHXdyh7

D. Service Provider grants Access Token

This resulted in the following JSON response containing our OAuth access_token:

{"token_type":"Bearer",

"expires_in":300,

"access_token":"ivBOdwGpGb3pY3gvPaK6D8W5Ldey”

}

Protocol Workflow





https://idp.idtel.com:9031/as/token.oauth2


OAuth 2.0 Benefits

• Security & Usability

– Bearer Tokens

• Revocation

• Granularity

• Use Cases*

• Passwords vs.

OAuth ===

creditcard vs.

checks

Scopes


OAuth 2.0 is Not for Authentication !!

• Bearer token is about

delegated rights, not

about the user authn

• Bearer token has no

audience restriction

– can’t check if it was

really meant for you

– Not bound to the client

• No guarantee that the

user is present

– no “authn statement”

semantics

• Redirect is not

authenticated or

integrity protected in

any way

– bearer = bearer and

nothing more

validate

client rs + as

user agent

get a token redirect

T

T

user info


OpenID Connect

• OAuth: general

mechanism to

authorize API access

• OpenID Connect:

profile for sharing

profile information

• Uses the authz code &

implicit grant types –

the pieces of OAuth

optimized for user-

consent scenarios

• Leverages the

authorization & token

endpoints & adds

identity-based params

to core OAuth

messages

Client

(RP)

User

Agent AS/OP

Resource

Server

UserInfo

a

b

1

3

a

a

2


SSO for Mobile Apps: Authorization Agent (AZA)

• Aggregate OAuth

flows and logins

• Bootstrap through

WebSSO with

OpenID Connect or

SAML

• Oauth-as-a-Service

+ SAML-as-a-

Service

OAUTH SSO


RECOMMENDATIONS

[section lead-in]


Something to think about: Cloud IAM strategy

• Multi-use case,

multi-device, multi-

channel, multi

protocol…

– Identity is the

connector

• Interoperability and

standards

• IAM not just an

internal technical

issue: also a

strategic business

enabler

• Architect for agility


• Implement your API for: – externalized authentication and authorization

– tokens instead of passwords

– consumer identity AND enterprise identity

• By leveraging identity we can: – address API access (server2server, mobile) in the

same way as Web SSO

– reuse existing security and identity policies

– connect your existing identity store

• Possibly implement this in a single system(!) – And be prepared for OAuth 2.0, OpenID Connect,

SCIM, SAML, …

Identity for APIs strategy


COME AND SEE US!

Hans Zandbelt

Twitter: @hanszandbelt

www.pingidentity.com

Technology

Who’s Knocking? Identity for APIs, Web and Mobile