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

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

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Who’s Knocking? Identity for APIs, Web and Mobile (20)

More from Nordic APIs (20)

Recently uploaded (20)

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