This presentation describes the token-agent implementation for openID Connect for authenticating native mobile apps provided by third parties. It presents a standards-based working solution for integrating loosely coupled native apps into a trust federation using. This allows for deeper integrated authentication services on Android and iOS without violating app-store policies. This presentation has been part of the EduID Mobile App workshop at SWITCH on 25 Apr. 2017. Thanks to Christoph Graf (SWITCH), Riccardo Mazza (USI), Michael Hausherr (FHNW), Goran Josic (USI), and Yann Cuttaz (USI).

1. FHO Fachhochschule Ostschweiz
EduID Mobile App
Use-cases, Concepts, Implementation

2. @phish108 @htwblc
Part I
Use Cases and Concepts

3. The “Cloud” from a Service Perspective
Clients
@phish108 @htwblc

4. The “Cloud” from a Device Perspective
Roaming
Profiles
@phish108 @htwblc

5. The “Cloud” from a User Perspective
Smart
Environments
@phish108 @htwblc

6. Shifting from Feature Services to Smart Environments
Glahn (2013). What we mean when we talk about mobile services. SIG Mobile Whitepaper @phish108 @htwblc

7. Personalization requires Authorization
Seite 6

8. Authorization is about Trust
Organization
Trusted
User &
App Store
Trusted
Mobile DeviceService Federation
Untrusted
Personal Data
Internet
@phish108 @htwblc

9. 1. OIDC for Responsive Web-Apps
2. AppAuth for tightly integrated native mobile apps
3. Token Agent Authorization for loosely coupled native apps
@phish108 @htwblc
3 Approaches

10. Approach 1: Responsive Web-Apps
(OpenID Connect / OAuth2, SAML)
@phish108 @htwblc

11. Open ID Connect: 3 Flows to Authorizations
@phish108 @htwblc
1. Implicit flow
• Get an authorization from an IDP for accessing a service with limited
session details
2. Code flow
• Receive an authorization code for fetching confidential session details
from the IDP
3. Hybrid flow
• Get an authorization from an IDP for accessing a service with
confidential session details in one step

12. OpenID Connect (OIDC)
26.04.2017Corporate IT, FHNW 11
«A Simple Identity layer on top of OAuth 2.0»
From the website (http://openid.net):
− OIDC is an interoperable authentication protocol based on the OAuth 2.0 family of
specifications. It uses straightforward REST/JSON message flows with a design goal of
«making simple things simple and complicated things possible». It’s uniquely easy for
developers to integrate, compared to any preceding Identity protocol.
− OIDC allows for clients of all types, including browser-based JavaScript and native
mobile apps, to launch sign-in flows and receive verifiable assertions about the identity
of signed-in users.

13. SAML vs OIDC vs OAuth
26.04.2017Corporate IT, FHNW 12
Simply said:
− SAML: single sign-on for enterprise users
− OAuth: API authorization between applications
− OIDC: single sign-on for consumers + API access
Token format:
− SAML: XML
− OIDC: JWT (JSON web token)
The whole story:
«Unifying Authentication & Delegated API Access for Mobile, Web and the Desktop with
OpenID Connect and OAuth2 by Dominick Baier»
https://vimeo.com/113604459

14. GET /authorize
?client_id=app1
&scope=openid profile
&redirect_uri=https://app.com/cb
&response_type=id_token token
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
Implicit Flow
26.04.2017Corporate IT, FHNW 13
− One of multiple flows (processes) defined in the specification
− Specifically designed for «untrusted clients» such as JavaScript apps
− Key steps:
− Client sends the request to the Authorization Server.
− Authorization Server authenticates the End-User, obtains consent, sends him/her back to the Client with an
ID Token and, if requested, an Access (Bearer) Token.
− Client validates the tokens and retrieves the End-User's Subject Identifier.
− Client uses the Access Token for calls to Backend Web Services

15. @phish108 @htwblc
Approach 2: Integrated Service Apps
or Service-bound Apps
(AppAuth)

16. © 2017 SWITCH | 15
Startseite Untertitel
Unternehmenspräsentation
Christoph Graf, Rolf Brugger
swisseduid@switch.ch
SIG Mobile, 25.4.2017 @SWITCH
Use case of a “Service-bound Mobile App”
SWITCHdrive App

17. SWITCHdrive
Sync & share on Swiss servers
Keep your data on your devices synchronized and share them
with your contacts – on secure safe servers
Your benefits
• Data in Switzerland
• Fast network connection to SWITCH
• Simple user activation
Customers
• Universities
• Hospitals
• Other institutions
Services
• SWITCHdrive- Serverfarm, based on
ownCloud
• High dissemination in academic
Switzerland (>80% of universities)

18. SWITCHdrive App –
The official mobile client
of the SWITCHdrive service
• SWITCH-branded, based on owncloud app
• Preconfigured with fixed endpoints for SWITCHdrive
• Feature set in line with SWITCHdrive capabilities
• Support limited to this app
Usage scenario description

19. • Controlling the user experience end-to-end
• Service branding opportunity (CI/CD)
• Needs to maintain an app
(development/adaptation/preconfiguration/testing,
mobile martketplaces, etc.)
• One single app to document and support
• No re-use opportunity of potentially compatible app
Service operator perspective

20. • Opportunity to develop, adapt, brand, preconfigure or
support app exclusively for specific services as a
contractor to service operator
• (Probably) no opportunity to offer alternatives to users
bypassing service operator
• Uses standard authentication mechanisms (AppAuth,
OAuth2, OIDC): availability of libraries, development
and testing tools, tutorials.
App developer perspective

21. www.switch.ch/30years
SWITCH – an integral part of the Swiss
academic community since 1987.

22. @phish108 @htwblc
Approach 3: EduID Mobile App
(Token-agent assertions)

23. • Multi-LMS learning app
• API dependent, not service dependent
• No separate backend service
• Entering and managing authorizations cumbersome
• Major UX barrier
• Specialized solution for some didactics
@phish108 @htwblc
The Story of Mobler

24. @phish108 @htwblc
How relevant are these cases for
your institution?

25. @phish108 @htwblc
Part II
EduID Mobile App Architecture

26. @phish108 @htwblc
EduID Mobile App Reference Architecture
1
234
5

27. • Focus on business logic
• Completely external SSO
• Federation independence
• Loose bounds with specific services and instances
• Independence of specific authorization mechanics
• Multi factor authorization
• Service-level authorization
• Customers binding
@phish108 @htwblc
Benefits for Developers

28. • Continuous but flexible authorization and access control
• Apps will not see forbidden service endpoints
• Apps will not know authorization endpoints
• Easier adoption of apps
• No immediate need for app customizations
@phish108 @htwblc
Benefits for Organizations

29. • One stop authorization and identity management
• No need to enter URLs in apps.
• No need to enter passwords all the time
• Transparent and explicit authorization of services
@phish108 @htwblc
Benefits for Actors

30. Requirements
• Minimum Changes compared to OpenID Connect implementations
• No Interference with existing OpenID Connect and AppAuth
• Only standardized concepts (RFC-level)
@phish108 @htwblc
Implementation Requirements
for Service Providers

31. Solution
• Variation of OAuth2/OpenID Connect Code Flow
• Trust-agent initiates the code request phase, directly
• No separate authorization step
• All request parameters are forwarded to the OAuth2 endpoints
• Service extends code request with the required OAuth2 scope
@phish108 @htwblc
Implementation Requirements
for Service Providers

32. @phish108 @htwblc
PHP-CodefromtheMoodleImplementation
if (array_key_exists("id", $_GET)) {
// Step 1: Code-flow, Hybrid-Flow
// normal use when the user comes via the login page
// triggers the authorization request
$callback->handleAuthorization();
}
elseif (array_key_exists("state", $_GET)) {
// Step 2: Code-flow, Hybrid-Flow
// response from the authorization endpoint
$callback->authorizeUser();
}
elseif (array_key_exists("assertion", $_GET)) {
// EduID Extension: rfc7521 forwarding
$callback->authorizeAssertion();
}
else {
// bad request or OAuth2 error
http_response_code(403);
exit;
}

33. public function authorizeAssertion() {
// rfc7521 forwarding: extend the incoming assertion parameters
$param = array_merge($_GET, ["scope"=> "openid profile email"]);
// Fetch the access-token and user–information
// - this is the same call as in step 2 of the Code Flow
$res = $this->callTokenEndpoint($param);
if (!$this->handleToken($res)) {
http_response_code(403);
}
}
@phish108 @htwblc
PHP-CodefromtheMoodleImplementation

34. Reduction of Business Logic
• Authorization request via mobile-OS instead of self-authorization
• Self-identification
• Service or service-capability demands
• Single or multi-endpoint handling
• Endpoint and token management (as usual)
@phish108 @htwblc
Implementation Requirements
for App Developers

40. App Authorization
for Service

42. Further reading http://htw.ac/eduid-mobile
@htwblc
http://htw.ac/blc-blog
FHO Fachhochschule Ostschweiz