OpenID Connect Speculations and Applications

Copyright ©2012 Ping Identity Corporation. All rights reserved.1
OpenID Connect
(and speculations about potential
applications, some of which will almost
certainly not come to fruition)
Paul Madsen
@paulmadsen

The OAuth 2.0 stack
2
OAuth 2.0
JWT, JWS, JWE

The OAuth 2.0 stack
3
OAuth 2.0
TVE
Green
Button
UMA OpenID Connect
JWT, JWS, JWE

The OAuth 2.0 stack
4
OAuth 2.0
TVE
Green
Button
UMA OpenID Connect
Native
SSO
MIM IoT
JWT, JWS, JWE

To be clear
Speculation
Native
SSO
MIM
IoT
1/Concreteness

Connect's Key Identity Extensions
•  UserInfo endpoint
– OAuth protected endpoint that provides
identity attributes about user
– (Think of it as a distributed NSA server)
•  ID Tokens
– Provides information about
authentication status of user
– (Think of it as a SAML assertion with
friends)
8

The OAuth stack
9
OAuth 2.0
TVE
Green
Button
UMA OpenID Connect
Native
SSO
JWT, JWS, JWE

Native SSO
•  OAuth 2.0 enables native mobile applications to
call their corresponding APIs
•  But OAuth 2 presumes each app will individually
obtain access tokens (for subsequent use)
•  As the number of native apps grows for a typical
user, usability burden of individually mediating this
token retrieval will grow
•  We need a model for 'Native SSO' as we have for
web apps
•  Introducing an 'Authorization Agent' (AZA) can do
so
10

AZA Pattern
11
App1
App2
AS
AS RS
RS
Device Browser
Native App1
Native App2
Client
Client

AZA Pattern
12
App1
App2
AS
AS RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA

AZA Pattern
13
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

AS
AZA Pattern – AZA Authn
14
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA

AZA Pattern – first application
15
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

16
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

17
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

AZA Pattern – second application
18
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

19
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

20
App1
App2
RS
RS
Device Browser
Native App1
Native App2
Client
ClientAZA
AS

portal
• Native app
• SSO for mix of
web & native apps

Standardization
•  A number of companies are working to
define a standardized framework to address
the AZA use case
•  Work will happen in the OpenID Foundation
•  We'll profile/extend Connect to add the
necessary AZA pieces
•  For more information
– http://openid.net/wg/napps/

Framework Components
AZA APP
APIAS
Device
• OpenID Connect profile/extension
• AppInfo API
• Inter app messaging
• Custom URL scheme etc
• Token validation
• Token wrapper

The OAuth stack
24
OAuth 2.0
TVE
Green
Button
UMA OpenID Connect
MIM?
JWT, JWS, JWE

MIM
•  Mobile Information Management is seen (by some)
as the logical end game for enterprises wishing to
secure their employee's device (BYOD or
otherwise)
•  Whereas MDM applies enterprise policy to the
whole DEVICE, and MAM applies policy to the
business APPLICATIONs, MIM applies policy to
only the business INFORMATION on the device
•  Everything else (Angry Birds, wedding photos, etc)
is left alone and so MIM is seen as better
compatible with BYOD
•  And yes it feels like DRM …..
25

OpenID Connect for MIM?
•  Connect provides the id_token & UserInfo
API – are they relevant to MIM?
•  MIM is really key management, ie ensuring
that
–  Biz data encrypted before delivery to mobile
applications
–  Decryption keys released to those apps only
when appropriate
•  We can use combination of Connect id_token
& UserInfo to move those keys around
26

Whiteboarding …..
AS RS
Device
App
1) AT
2) request + AT
3) validate (AT)
4) status + k
6) enc(data)
9) Use k to decrypt data
5) Encrypt data with k
AT == access token
k == symmetric key
PS
7) License?+ AT
8) license(k)

The OAuth stack
28
OAuth 2.0
TVE
Green
Button
UMA OpenID Connect
IoT??
JWT, JWS, JWE

Identity of Things?
•  Internet of Things proposes that every device
(sensor, appliance, machine etc) will be
connected
•  Every thing will have it's own identity, but will often
act on behalf of a given user
•  So how
–  Do we reconcile these multiple identities?
–  Do things authenticate to their data sharing endpoints?
–  Do we ensure that the user has desired level of control
over how their things share data?

•  Connect could provide identity layer for (some of)
IoT
–  Things obtain access & id_tokens and use them on API
calls
–  User controls issuance of those tokens, and so
•  Tokens can be mapped to user identity
•  User retains control of data sharing
•  Standards like CoAP and MQTT define messaging
protocols more optimized to things but so far have a
relatively basic identity model (eg passwords over
TLS)
•  Can we imagine a CoAP binding for Connect? That
defines how to
–  Carry tokens on CoAP calls
–  Proxying between CoAP & HTTP
OpenID Connect?

Thanks (for
putting up my
with speculation)

OpenID Connect Speculations and Applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to OpenID Connect Speculations and Applications

Similar to OpenID Connect Speculations and Applications (20)

More from Nordic APIs

More from Nordic APIs (20)

OpenID Connect Speculations and Applications