Mobile Native app OAuth  decision framework       Paul Madsen       Ping Identity
Premise• Based on a number of different deployment  characteristics, you will be led to/from choices  you need to make abo...
Characteristics1. Local authn vs 3rd party authn – will the AS authenticate the user   of the app itself, or will it rely ...
Key Choices1. User authentication mechanism - Will the app use a   browser as the means of getting the user   authenticate...
User authentication mechanism                                   Embedded                       External    browser        ...
Embedded                  External   browser                                                  Inline                  brow...
Embedded                  External       browser                                                    Inline                ...
Embedded                  External     browser                                                   Inline                  b...
Embedded                  External      browser                                                  Inline                  b...
Embedded                  External       browser                                                    Inline                ...
Embedded                  External       browser                                                   Inline                 ...
Comparison of different authn models   Embedded browser                    Inline                                   •No ne...
Upcoming SlideShare
Loading in...5
×

Mobile Native OAuth Decision Framework

1,522

Published on

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

Published in: Technology, Business
1 Comment
2 Likes
Statistics
Notes
  • 1) How much control does the server have over how 3rd party apps collect the credentials, esp. over whether they use an ext browser or an emb one?
    2) In slide 12, maybe a '+' or a '-' in front one each attribute would help. E.g '+ Enables SSO' and '- Pwd shared with 3rd party'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,522
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Mobile Native OAuth Decision Framework

  1. 1. Mobile Native app OAuth decision framework Paul Madsen Ping Identity
  2. 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. 3. Characteristics1. 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. 4. Key Choices1. 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. 5. User authentication mechanism Embedded External browser Inline browser Custom Authz code Cookie Implicit Title RO Creds OAuth grant typeToken passing mechanism
  6. 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. 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 shouldnt 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. 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. 9. Embedded External browser Inline browser Phishing risk?Custom Authz code Cookie Implicit Title RO Creds Justification – if the app distribution channel cant guarantee a rogue app cant claim the custom scheme, may lead to preference for embedded browser or inline
  10. 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. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×