CIS 2015- Mobile SSO: Are We There Yet? - Brian Campbell

MOBILE SSO
ARE WE THERE YET?
BRIAN CAMPBELL
@__b_c

Copyright © 2015 Brian Campbell. All rights reserved. 2
Formalities, Introductions, etc.
• I work @ Ping
• You might know me as ‘that guy’ with the camera
• Slides will be available
– at http://www.slideshare.net/briandavidcampbell
– & at https://twitter.com/__b_c
• 2 underscores +
• b +
• 1 underscore +
• c

Yeah, that guy

Formalities, Introductions, etc.
• I work @ Ping
• You might know me as ‘that guy’ with the camera
• Slides will be available
– at http://www.slideshare.net/briandavidcampbell
– & at https://twitter.com/__b_c
• 2 underscores +
• b +
• 1 underscore +
• c

• Disclaimers
– Views or opinions presented herein are solely my own
and do not necessarily represent those of the my
employer
– Wholly unqualified to talk about mobile
– Primarily do server side development
– And not even very much of that anymore
• So, um… WTF?
– I know a few people involved with CIS
– And I do use a mobile phone…
My ‘Safe Harbor’ Slide

Though not very well

But Sometimes…
An outsider’s perspective can help see where
things just aren’t quite right

as demonstrated by a semi-contrived little story about me and my phone
Premise:
Single Sign-On just isn’t quite right
on mobile

I’m very busy and important
As you can
see by my
opulent travel
budget.

So, while I am one of those luddites who
still prefers a real computer for work,
sometimes I have to use my phone…

Just trying to join a meeting
while out on the road.

Please excuse any
intermittent time travel.
I had some technical
difficulties with
something called “focus”
and had to reshoot a few
images.

There’s my meeting!

(This happened on first use a
long time ago)

!

Awkward
Transition

• Behind the Scenes
– Web Single Sign-On
– OAuth 2.0 (ish)

Web Single Sign-On in one Slide
• Typically
– SAML 2.0
– OpenID Connect
• But also
– SAML 1.1/1.0
– OpenID 2.0
– WS-Federation
• And maybe
– Facebook Connect/Login
– Whatever Twitter does
– Various non-standard
approaches
Identity
Provider
(IDP)
Service
Provider
(SP)
Web Single Sign-On
(SSO)
You
Only
Login
Once

OAuth 2.0 in one slide
• client: An application obtaining
authorization and making
protected resource requests.
– Native app on mobile device
• resource server (RS): A server
capable of accepting and
responding to protected resource
requests (typically APIs).
• authorization server (AS): A
server capable of issuing tokens
after successfully authenticating
the resource owner and obtaining
authorization.
A few other OAuth terms
• Access token (AT) – Presented by client when accessed protected
resources at the RS
• Refresh token (RT) - Allows clients to obtain a fresh access token
without re-obtaining authorization
• Scope – A permission (or set of permissions) defined by the AS/RS
• Authorization endpoint – used by the client to obtain authorization
from the resource owner via user-agent redirection
• Token endpoint – used for direct client to AS communication
• Authorization Code – One time code issued by an AS to be
exchanged for an AT.
Client
Resource
Server
Get a token
Use a token
Authorization
Server

Web SSO + OAuth = Mobile SSO
Device
Native
App
System Browser
1
https:// Home Service
1
2
3
Authorization
Endpoint
Token
Endpoint
3
45
Enterprise or
Social Identity
Provider

(1) Request Authorization
• When user first needs to access some
protected resource (not logged in), the app
launches the system browser with an
authorization request
• ‘IDP Discovery’ can be done in the native
application
Device
Native
App
System Browser
1
1
Authorization
Endpoint
Token
Endpoint
Enterprise or
Social Identity
Provider
https://as.example.com/as/authz.oauth2?client_id=org.example.myapp&response_type=code
&scope=update_status&idp=pingidentity.com&code_challenge=7gEsCAcCLtCTbDl2fml2z
A quick
note about
Apple…

(1a) PKCE
https://as.example.com/as/authz.oauth2?client_id=org.example.myapp&response_type=code
&scope=update_status&idp=pingidentity.com&code_challenge=7gEsCAcCLtCTbDl2fml2z
• Proof Key for Code Exchange by
OAuth Public Clients (PKCE)
– Binds the code exchange to the authorization
request
– (RFC in waiting) https://tools.ietf.org/html/draft-ietf-oauth-spop

(2) Authenticate and Approve
• Redirect to IDP for SSO & Service Provider
is the SP
Device
Native
App
System Browser
2
Authorization
Endpoint
Token
Endpoint
Enterprise or
Social Identity
Provider
• User approves the
requested access
– (don’t skip this)

(3) Handle Callback
• Authorization server returns control to the
app using HTTP redirection and includes an
authorization code
– URI with a custom scheme registered to the app
• Reversed domain name as redirect_uri
scheme
– Resistant to accidental collisions
– Proof of domain ownership provides better recourse
against malicious collisions
Device
Native
App
System Browser
3
Authorization
Endpoint
Token
Endpoint
3
Enterprise or
Social Identity
Provider
HTTP/1.1 302 Found
Location: org.example.myapp://oauth.cb?
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4

(4) Trade Code for Token(s)
Device
Native
App
System Browser
Authorization
Endpoint
Token
Endpoint
4
Enterprise or
Social Identity
Provider
POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
client_id=org.example.myapp&
grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
code_verifier=7gEsCAcCLtCTbDl2fml2z
token endpoint request

(4a) PKCE Again

(4b) Trade Code for Token(s)
Device
Native
App
System Browser
Authorization
Endpoint
Token
Endpoint
4
Enterprise or
Social Identity
Provider
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
{
"token_type":"Bearer",
"expires_in":3600,
"access_token":"PeRTSD9RltacecQriuFfsxV41”,
"refresh_token":"uyAVrtaccLZ2qPzI8rQ5ltckCdGJsz8XE58esc”
}
token endpoint response

(5) Use Access Token
Authenticate/authorize calls to the
protected APIs by including AT in the
HTTP Authorization header
Device
Native
App
System Browser
Authorization
Endpoint
Token
Endpoint
5
Enterprise or
Social Identity
Provider
POST /api/update-status HTTP/1.1
Host: rs.example.org
Authorization: Bearer
PeRTSD9RltacecQriuFfsxV41
Content-Type: application/json
{"status" :
"almost done with this presentation"}

Rinse and Repeat
• If All Goes well,
• And if not, HTTP 401
• Use the refresh token to get a new access token
• And if that doesn’t work or you don’t have a
refresh token, initiate the authorization request
flow again
HTTP/1.1 200 OK

Some Folks Like to …
Device
Native
App
System Browser
1
1
2
3
Authorization
Endpoint
Token
Endpoint
3
45
Enterprise or
Social Identity
Provider

… Use a Web-View
Device
Native
App
1
1
2
3
Authorization
Endpoint
Token
Endpoint
3
45
Web-View
Enterprise or
Social Identity
Provider
but
…

The Web-View Anti-Pattern
• Usability Issues
– No shared context (cookie)
– Requires sign-in once per app even when web SSO is possible
• Security Issues
– Web-view typically isn’t sandboxed from invoking app so
credentials and authentication cookies can be stolen
– Requires/encourages users to enter credentials without the
address bar and associated visual cues of site authenticity
(HTTPS)
• Missing Features
– Some web-views unable to access to client certificates
– Generally unable to use password managers, etc.

What about OpenID Connect?
• A simple[sic] single sign-on
and identity layer on top
of OAuth 2.0
• Adds an ID Token (JWT)
for user authentication to
the client
• And a bunch of other
stuff

What about OpenID Connect?
• Great for the
web SSO part
• Can be layered
on the OAuth
part
Device
Native
App
System Browser
1
1
2
3
Authorization
Endpoint
Token
Endpoint
3
45
Enterprise or
Social Identity
Provider

What about NAPPS?
• Intended to be a profile
of OpenID Connect to
enable an SSO model
for native applications
installed on mobile
devices
• A Token Agent as the
shared context

NAAPS NAPPS is Great!
• It’s just not real (yet, anyway)
this one
um, no
“eventually”

Don’t Sleep on NAPPS?
• But not totally
incompatible with
approach
discussed herein
– (latest thinking,
anyway)

And really, who couldn’t use more NAPPS?

Near Term Recommendations
• Use OAuth 2.0 + PKCE
– & maybe OpenID Connect
• Use Web SSO
• Prompt for user consent (every time)
• Use the System Browser
• Use a reversed Internet domain name in
the custom scheme for the callback URI

MOBILE SSO
ARE WE THERE YET?
BRIAN CAMPBELL
@__b_c
TH
AN
K
S! (tim
e
perm
itting)
QUESTIONS?

CIS 2015- Mobile SSO: Are We There Yet? - Brian Campbell

More Related Content

Similar to CIS 2015- Mobile SSO: Are We There Yet? - Brian Campbell (20)

More from CloudIDSummit (20)

Recently uploaded (20)

CIS 2015- Mobile SSO: Are We There Yet? - Brian Campbell