Presents a framework for choosing amongst different deployment options for using OAuth for mobile native apps

1. Mobile Native app OAuth
decision framework
Paul Madsen
Ping Identity

2. Premise
• Based on a number of different deployment
characteristics, you will be led to/from choices
you need to make about
– How you authenticate the user
– How you get the tokens to the native app
– The OAuth grant type to use
• Note – the rules are not hard & fast
• Generally, certain characteristics will tend to
preclude particular choices

3. Characteristics
1. Local authn vs 3rd party authn – will the AS authenticate the user
of the app itself, or will it rely on SSO from a 3rd party IdP?
2. Own app vs do not own app – does the AS/RS create and distribute
its own native application (eg Salesforce Chatter) or is the app
created by a 3rd party (e.g. Seesmic as client of Chatter)
3. Need refresh vs do not need refresh – do you need refresh tokens
to enable long-lived SSO?
4. Does the app distribution channel guard against rogue apps getting
installed and creating a phishing risk?
5. Is it important to keep user in application context or not?
6. Is the app 'hybrid', ie a native shell around web app internals?

4. Key Choices
1. User authentication mechanism - Will the app use a
browser as the means of getting the user
authenticated? If so, will the browser be separate or
embedded in the app? If not, will the app collect the
user credentials directly?
2. OAuth grant type – authz code, implicit, or RO
creds?
3. Token passing mechanism - If you use a browser for
user authentication, how will you get the token from
the browser to the native app, via cookie, HTML
title, or a custom URI scheme?

5. User authentication mechanism
Embedded
External browser
Inline
browser
Custom Authz code
Cookie Implicit
Title RO Creds
OAuth grant type
Token passing mechanism

6. Embedded
External browser
Inline
browser
Need 3rd party
authn?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification – if you need 3rd party authn, you likely want a
browser for SSO. The alternative is collecting the creds in the
app, and having the AS proxy the verification

7. Embedded
External browser
Inline
browser
Don’t own
app?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification – if the AS/RS doesn’t distribute its own app, it
shouldn't ask user to enter creds into a 3rd party app, or into an
embedded browser, in which the native app could see
passwords presented

8. Embedded
External browser
Inline
browser
Need
refresh?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification – the implicit grant doesn’t
support refresh tokens

9. Embedded
External browser
Inline
browser
Phishing
risk?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification – if the app distribution channel can't guarantee a rogue app
can't claim the custom scheme, may lead to preference for embedded
browser or inline

10. Embedded
External browser
Inline
browser
Keep user in
app context?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification - external browser takes user out of application
context. And if you are embedding the browser, the custom
scheme may be unnecessary overhead.

11. Embedded
External browser
Inline
browser
Hybrid app?
Custom Authz code
Cookie Implicit
Title RO Creds
Justification - a hybrid app relies on an embedded browser by
definition.

12. Comparison of different authn models
Embedded browser Inline
•No need to leave app context
•Pwd shared with 3rd party
•Enables SSO •App owns login UI
•Enables strong authn
•AS owns login UI
•Visual trust cues
•Authn can leverage stored pwds
•Authn can leverage existing sessions
Separate browser