Mobile Single Sign-On (Gluecon '15)

Mobile Single Sign-OnOAuth 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…


Though Not Very Well


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!


!


Awkward

Transition

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.

ClientResource

Server

Get a token

Use a token

AuthorizationServer


Web SSO + OAuth = Mobile SSO

Device

NativeApp

System Browser

1

https:// Home Service

12

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

NativeApp

System Browser

1


1


Token Endpoint


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

NativeApp

System Browser


2


Token Endpoint


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

NativeApp

System Browser


3


Token Endpoint

3


Provider

HTTP/1.1 302 FoundLocation: org.example.myapp://oauth.cb?code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4


(4) Trade Code for Token(s)

Device

NativeApp

System Browser



Token Endpoint

4


Provider

POST /as/token.oauth2 HTTP/1.1Host: as.example.comContent-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 OKContent-Type: application/json;charset=UTF-8Cache-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.1Host: as.example.comContent-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 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-store

{ "token_type":"Bearer", "expires_in":3600, "access_token":"PeRTSD9RltacecQriuFfsxV41”, "refresh_token":"uyAVrtaccLZ2qPzI8rQ5ltckCdGJsz8XE58esc”}

token endpoint request

token endpoint response


(5) Use Access TokenAuthenticate/authorize calls to the protected APIs by including AT in the HTTP Authorization header

Device

NativeApp

System Browser



Token Endpoint

5


Provider

POST /api/update-status HTTP/1.1Host: rs.example.orgAuthorization: Bearer PeRTSD9RltacecQriuFfsxV41Content-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

NativeApp

System Browser

1


12

3


Token Endpoint

3

45


Provider


… Use a Web-View

Device

NativeApp

1


12

3


Token Endpoint

3

45

Web-View


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

NativeApp

System Browser

1


12

3


Token Endpoint

3

45


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

Mobile Single Sign-On (Gluecon '15)

Internet

Transcript of Mobile Single Sign-On (Gluecon '15)