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

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