Mobile Single Sign-On (Gluecon '15)

Mobile Single Sign-On
OAuth 2.0, OpenID Connect, & NAPPS.
Why doesn’t anything work?
Can we do better?
Brian Campbell
@__b_c

Copyright © 2015 Brian Campbell. All rights reserved. 2
Introductions
• Slides will be available
• at http://www.slideshare.net/briandavidcampbell
• & @ https://twitter.com/__b_c
– 2 underscores +
– b +
– 1 underscore +
– c
– (My name isn’t exactly uncommon)
Brian Campbell
As a Distinguished Engineer for Ping Identity, Brian
Campbell aspires to one day know what a Distinguished
Engineer actually does for a living. In the meantime,
he’s tried to make himself useful with little things like
designing and building much of PingFederate, the
product that put Ping Identity on the map. When not
making himself useful, he contributes to various identity
and security standards including a two-year stint as co-
chair of the OASIS Security Services Technical Committee
(SAML) and is currently contributing to OAuth and JOSE
in the IETF as well as OpenID Connect and NAPPS. He
holds a B.A., magna cum laude, in Computer Science
from Amherst College in Massachusetts. Despite
spending four years in the state, he has to look up how
to spell “Massachusetts” every time he writes it.

Introductions Disclaimer
• Qualifications
– Wholly unqualified to talk about mobile
– Primarily do server side development
– And not even very much of that anymore
• So, um… WTF?
– I used to work with Norlin
– And I do use a mobile phone…

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

Premise
Single Sign-On just isn’t quite right on mobile

Premise demonstrated by
a semi-contrived little
story about me and my
phone

I’m very busy and important
As demonstrated 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.

Trying to join a meeting while
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!

Into some details of what was, could, or should be happening there.

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)

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

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

(1a) PCKE
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
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 request
token endpoint response

(4a) PKCE Again
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
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 request
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)
• But not totally incompatible
with approach discussed
herein
– (latest thinking, anyway)

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

Thanks!(and time permitting)
Questions?(there are no stupid questions, only stupid answers and I’m tremendously
qualified to deliver such answers)
Brian Campbell
@__b_c

Mobile Single Sign-On (Gluecon '15)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Mobile Single Sign-On (Gluecon '15)

Ähnlich wie Mobile Single Sign-On (Gluecon '15) (20)

Mehr von Brian Campbell

Mehr von Brian Campbell (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Mobile Single Sign-On (Gluecon '15)