mobile native oauth decision framework
DESCRIPTION
Presents a framework for choosing amongst different deployment options for using OAuth for mobile native appsTRANSCRIPT
Mobile Native app OAuth decision framework
Paul MadsenPing Identity
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
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?
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?
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
User authentication mechanism
Token passing mechanism
OAuth grant type
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Need 3rd party authn?
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
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Don’t own app?
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
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Need refresh?
Justification – the implicit grant doesn’t support refresh tokens
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Phishing risk?
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
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Keep user in app context?
Justification - external browser takes user out of application context. And if you are embedding the browser, the custom scheme may be unnecessary overhead.
Custom
Cookie
Title
Externalbrowser
RO Creds
Implicit
Authz code
Embeddedbrowser
Inline
Hybrid app?
Justification - a hybrid app relies on an embedded browser by definition.
Comparison of different authn models
InlineEmbedded browser
•Pwd shared with 3rd party•App owns login UI
•Visual trust cues•Authn can leverage stored pwds•Authn can leverage existing sessions
• No need to leave app context
•Enables SSO•Enables strong authn•AS owns login UI
Separate browser