Denver Startup Week '15: Mobile SSO

Mobile Single
Sign-On
Are we there yet?
BRIAN CAMPBELL
@__b_c

@__b_c
Copyright © 2015 Brian Campbell. All rights reserved. 2
Formalities, Introductions, etc.
• No way this will take 90 minutes
• There should be food and beer
• Slides will be available
– at http://www.slideshare.net/briandavidcampbell
– & via https://twitter.com/__b_c
• 2 underscores +
• b +
• 1 underscore +
• c

@__b_c
Formalities, Introductions, etc.
• I’ve worked @ Ping Identity for over a decade
• Ping is a Denver based ‘startup’ solving
complex identity challenges
Tel Aviv

@__b_c
I should mention that…

@__b_c

@__b_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?
– Ping sponsored Denver Startup Week
– And I do use a mobile phone…
My ‘Safe Harbor’ Slide

@__b_c
Though not very well

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

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

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

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

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

@__b_c

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

@__b_c

@__b_c
There’s my meeting!

@__b_c

@__b_c
(This happened on first use a
long time ago)

@__b_c

@__b_c
So…
What went wrong there?

@__b_c
What we want to happen
1. Be able to login to the
SaaS native applications
with existing Ping
credentials and not some
new login unique to each
SaaS

@__b_c
with existing Ping
SaaS
2. Be able to access
multiple SaaS native
applications throughout
the day after only a single
authentication to Ping

@__b_c
with existing Ping
SaaS
By combining
SAML & OAuth
protocols

@__b_c
with existing Ping
SaaS
By combining
SAML & OAuth
protocols
Concur effectively
forgot that that I
had already
logged in

@__b_c
How did Concur forget?
1. When first logged in to Ping as part of accessing
the Webex app, a cookie was set in the browser
I was using.
2. That cookie acts as a record of the login. When
next seen by the authentication system, it won’t
prompt again for an explicit login (unless
expired)
3. When Concur needed me authenticated by
Ping, it used a different sort of browser, a
webview
4. Cookies aren’t shared across these two different
browser types
5. The cookie that was set earlier in the first
browser wasn’t available, so I was prompted
again to login

@__b_c
That’s what went wrong
Concur used a ‘webview’

@__b_c
Why Concur? Why?
• Until recently mobile app developers had only two choices for
displaying web content (such as login pages)
• The external system browser (e.g. Safari or Chrome) or a
webview, in which the web content appears as part of the
app’s own user interface
• System browser
– better security characteristics
– cookie sharing (and so SSO across apps)
• Webview
– better UX

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

@__b_c
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 other non-standard
approaches
Identity
Provider
(IDP)
Service
Provider
(SP)
Web Single Sign-On
(SSO)

@__b_c
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
Authorization
Server

@__b_c
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

@__b_c
(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…

@__b_c
(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, pronounced "pixy"
– Binds the code exchange to the authorization
request
– Newly minted RFC 7636

@__b_c
(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)

@__b_c
(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

@__b_c
(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

@__b_c
(4a) PKCE Again

@__b_c
(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

@__b_c
(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"}

@__b_c
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

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

@__b_c
… 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…

@__b_c
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.

@__b_c
Hope Springs Mobile
• Latest versions of iOS & Android add a
third option for displaying web content
– iOS 9 Safari View Controllers
– Android Chrome 45 Chrome Custom Tabs
• Both provide new browser window with security
advantages and shared context of the system
browser but UX comparable to webviews

@__b_c
Wait, 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

@__b_c
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

@__b_c
Near Term Recommendations
• Use OAuth 2.0 + PKCE
– & maybe OpenID Connect
• Use Web SSO
• Prompt for user consent (every time)
• Use new View Controllers & Custom Tabs
– Fallback to using the System Browser
• Use a reversed Internet domain name in the
custom scheme for the callback URI

@__b_c
Useful Links (1997 Style)
• Mobile SSO Developers Guide
– https://developer.pingidentity.com/en/resources/napps-native-app-sso.html
• OAuth 2.0 for Native Apps
– https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps
• JWT Library for Java/Android
– https://bitbucket.org/b_c/jose4j/
• An old blog post
– https://www.pingidentity.com/en/blog/2015/07/06/mobile_sso_are_we_there_yet.html

Denver Startup Week '15: Mobile SSO

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (7)

Semelhante a Denver Startup Week '15: Mobile SSO

Semelhante a Denver Startup Week '15: Mobile SSO (20)

Mais de Brian Campbell

Mais de Brian Campbell (10)

Último

Último (20)

Denver Startup Week '15: Mobile SSO