Single sign-on Across Mobile Applications from RSAConference

10,167 views
9,692 views

Published on

How to implement a standards-based architecture for mobile app Single Sign-On - Presentation from RSA Conference -

Single sign-on Across Mobile Applications from RSAConference

  1. 1. Single sign-on across mobile applicationsFrancois LascellesChief architectLayer 7 Technologies
  2. 2. Why SSO matters? Adoption UX Layer 7 Confidential 2
  3. 3. Per-app SSO vs across-app SSO Per-App X-app X-app and X-domainWeb Cookies Cookies (domain • SAMLapps cookies) • Social login • Open ID ConnectMobile OAuth access tokensapps ? … and x-device … Layer 7 Confidential 3
  4. 4. Mobile app isolation User-agent Domain A Webapp 1 Cookie domain A Webapp 2 webapps Cookie domain B Webapp 3 (can be different parties) APP A Access token 1 Domain A API 1 mobile apps APP B API 2 Access token 2 APP C API 3 Access token 3 Layer 7 Confidential 4
  5. 5. Why extending SSO across apps? 1/21. Provider avoids managing user accounts IdP  Authenticate once trust  Consent to multiple providers Provider  By delegating authentication to a User Accounts Sessions trusted IdP, multiple providers User name User Shared secret State avoid managing user accounts Email and effectively provide SSO UX Layer 7 Confidential 5
  6. 6. Why extending SSO across apps? 2/22. A group of coordinated apps domain - Example: a set of application targeting BYOD App A App B App C  Authenticate once  Consent to multiple applications IdP Layer 7 Confidential 6
  7. 7. Enablers Client side  Provider side - Because each app works in isolation, - API infrastructure built-in with or there needs to be an app-to-app integrating with federation coordination - Even traditional web-based redirections require to switch between relying party app and browser app ID Federation API Security-as-a-service Infrastructure Apps Layer 7 Confidential 7
  8. 8. Client side redirections and callback  On iOS, apps can switch between each other and pass information through the redirection URL - Each app registers its own URL scheme - Calling such a URL switches to the other app - App gets information back by providing a callback URL tailored to its own scheme step 1 openURL AppA://something?callback=AppB://somethingelse App A App BopenURL AppB://somethingelse?arg=that_thing_you_need step 2 Layer 7 Confidential 8
  9. 9. Client side redirections and callback (continued)  Is that secure enough to pass a token? APPLE: “If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme. ” --link Layer 7 Confidential 9
  10. 10. Redirection/callback limitations and risks What‟s at stake? Social - An app tricks you into letting it get an access token to call your social provider on your behalf - Malicious app discovers your email - Posts something embarrassing on your wall (maybe)  Enterprise - An app tricks you into letting it getting an access token meant for an enterprise app - Malicious app now has access to all the same data as the app it pretended to be Layer 7 Confidential 10
  11. 11. Alternatives Note: on iOS 6, facebook login is „built-in‟ - Once an app is authorized, there are no redirections required and the exchange is presumably more secure But what if you don‟t trust the built-in social id broker? Or what if you want to implement your own SSO across a set of coordinated applications? - E.g. A set of enterprise apps targeting BYOD Layer 7 Confidential 11
  12. 12. KeyChain Groups KC A KC B Shared Key Chain App A App B App A App B Applications signed by the same developer key can share a key chain Combining redirection/callbacks with keychain groups enables a more secure delegated authentication - You can still pass scope between applications using URL schemes - But the sharing of information between these apps can go through the secure KeyChain group Layer 7 Confidential 12
  13. 13. Provider side enablers: OAuth  OAuth is the standard for an app to get an access token - The access token is what is used to consume APIs by the app  OAuth 2.0 defines different grant types (handshakes) for different situations1. OAuth handshake access token OAuth Authorization Server IdP2. API consumption OAuth Resource Server Backend API Layer 7 Confidential 13
  14. 14. Provider-side enablers: OpenID Connect  NOT OpenID  Mimics social login pattern, but standardized  Leverage an OAuth handshake to delegate authentication OpenID Connect IdP1. OIDC handshake OAuth Authorization Server access token Id token2. Get user info /userinfo Now I know who user is Layer 7 Confidential 14
  15. 15. Federating OAuth using SAML draft-ietf-oauth-saml2-bearer-xx - The SAML Bearer grant type lets an application get an access token in exchange for a SAML assertion - API Provider trusts ID Provider‟s signing certificate which is verified as part of the OAuth handshake ID Provider • SAML Web browser SSO • STS handshake Output: SAML Client API Provider application OAuth SAML Bearer Grant Output: access token Layer 7 Confidential 15
  16. 16. Federating OAuth using JWT draft-ietf-oauth-jwt-bearer-xx - The JWT Bearer grant type lets an application get an access token in exchange for a JSON Web Token (JWT) - API Provider trusts ID Provider‟s JWS signature which is verified as part of the OAuth handshake (RSA or HMAC) - The JWT can be issued as part of a standard OpenID Connect handshake ID Provider OpenID Connect Handshake Output: id token (JWT) Client API Provider application OAuth JWT Bearer Grant Output: access token Layer 7 Confidential 16
  17. 17. Federating OAuth across multiple APIs The same SAML or JWT can be trusted by multiple APIs ID Provider OpenID Connect Handshake Output: id token (JWT) trust Client API A application OAuth JWT Bearer Grant Output: access token API B Layer 7 Confidential 17
  18. 18. Applicability to X-app mobile SSO On iOS, the JWT is stored in a shared keychain group This is only accessible to applications signed by a common developer key (enterprise key) App Group KeyChain Group PUT OpenID Connect Identity +id token (JWT) Delegate App API Provider • Access Control GET • IdP +access token App 2 OAuth JWT Bearer Grant +access token App 1 Layer 7 Confidential 18
  19. 19. Role of various technology in mobile SSO?  WAM - Focuses on Web - Can be leveraged for management of permissions as part of mobile session handling  MDM - Focuses on device-side security - MAM can include user auth  API Management - API access control - Integrate with existing federation mechanism in place  VPN Connections - Does not provide application level security (no API access control) - Back door security hole in a mobile device - Better to enable strong auth from app to perimeter Layer 7 Confidential 19

×