1400 ping madsen-nordicapis-connect-01

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


Native SSO MIM IoT

JWT, JWS, JWE


To be clear S

pecu

latio

n

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


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

Client AZA


AZA Pattern

13

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS


AS

AZA Pattern – AZA Authn

14

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA


AZA Pattern – first application

15

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS



16

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS



17

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS


AZA Pattern – second application

18

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS



19

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

AS



20

App1

App2

RS

RS

Device Browser

Native App1

Native App2

Client

Client AZA

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

API AS

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


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


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)

1400 ping madsen-nordicapis-connect-01

Documents

Transcript of 1400 ping madsen-nordicapis-connect-01