Single sign-on Across Mobile Applications from RSAConference
Download as PPTX, PDF9 likes11,537 views
The document discusses single sign-on (SSO) across mobile applications, highlighting the benefits of extending SSO for improved user experience and security. It covers various mechanisms such as OAuth and OpenID Connect, along with potential risks associated with redirection and callback methods. Additionally, solutions such as shared keychains and federating OAuth with SAML and JWT are explored for enhancing secure authentication processes among coordinated applications.
Single sign-on Across Mobile Applications from RSAConference
- 1. Single sign-on across mobile applications Francois Lascelles Chief architect Layer 7 Technologies
- 2. Why SSO matters? Adoption UX Layer 7 Confidential 2
- 3. Per-app SSO vs across-app SSO Per-App X-app X-app and X-domain Web Cookies Cookies (domain • SAML apps cookies) • Social login • Open ID Connect Mobile OAuth access tokens apps ? … and x-device … Layer 7 Confidential 3
- 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. Why extending SSO across apps? 1/2 1. 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. Why extending SSO across apps? 2/2 2. 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. 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. 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 B openURL AppB://somethingelse?arg=that_thing_you_need step 2 Layer 7 Confidential 8
- 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. 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. 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. 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. 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 situations 1. OAuth handshake access token OAuth Authorization Server IdP 2. API consumption OAuth Resource Server Backend API Layer 7 Confidential 13
- 14. Provider-side enablers: OpenID Connect NOT OpenID Mimics social login pattern, but standardized Leverage an OAuth handshake to delegate authentication OpenID Connect IdP 1. OIDC handshake OAuth Authorization Server access token Id token 2. Get user info /userinfo Now I know who user is Layer 7 Confidential 14
- 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. 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. 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. 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. 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