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

who’s knocking? identity for apis, web and mobile

Technology

ping identity corporation

identity apis

aboutdelegated rights

api access openid

ouroauth access

browser access cloud

user authn bearer token

apis of paasofferings