Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Data Synchronization Patterns in
Mobile Application Design
Eric Maxwell

Credible Software
What to Expect
Synchronizing
Data
Data Format & Protocol
Efficiency
Security
• Privacy
• Integrity & Trust
• Authentication...
Example App
• Paid subscription application
• Ohio’s Premier Events
• Users can see events but not update
• Admin can upda...
Android Client
Login Register Find Events
iOS Client
Login Register Find Events
Data Format & Protocol Choice
Synchronizing
Data
Data Format & Protocol
Open Ecosystem
• Exposing resources to public 3rd party clients (ex. Facebook)
Closed Ecosystem
• Exposing resources to clients that you also control
Which approach is best?
Key Questions
• What do existing systems & data look like in my organization?
• Is it vitally important that I have transa...
RPC vs SOAP vs REST
https://dzone.com/articles/api-best-practices-plan-your
Examples
https://myrestservice.com/api/events/37/registrations/128
Examples
https://myrestservice.com/api/events/37/registrations/128
URI
Examples
https://myrestservice.com/api/events/37/registrations/128
Nouns
Examples
https://myrestservice.com/api/events/37/registrations/128
Nouns
Verbs tell what we are doing
Examples
https://myrestservice.com/api/events/37/registrations/128
Depends on the verb
HTTP METHOD

(verb)
ACTION
GET Get ...
Searching
/api/events
HTTP GET
/api/events?type=conference
Find All
Find All Events of type ‘conference’
What we’ve Covered
Synchronizing
Data
Data Format & Protocol
Efficiency
Synchronizing
Data
Data Format & Protocol
Efficiency
Always use compression
As simple as adding the following to your application.yml
server:

tomcat:

compression: on

compre...
Searching
/api/events
HTTP GET
/api/events?type=conference
Find All
Find All Events of type ‘conference’
What if we want o...
Synchronization Tokens
/api/events?after=b72cef Find All Events after this ‘token’
Sync tokens act as a bookmark for new f...
Synchronization Tokens in Action
1. HTTP GET /api/events?after=
Synchronization Tokens in Action
1. HTTP GET /api/events?after=
2. Server Responds with all events & token
Synchronization Tokens in Action
1. HTTP GET /api/events?after=
2. Server Responds with all events & token
3. HTTP GET /ap...
Synchronization Tokens in Action
1. HTTP GET /api/events?after=
4. Server Responds with events after token
2. Server Respo...
Client Perspective
• Unaware of Token Meaning
• Knows how to use the token
Client Perspective
• Unaware of Token Meaning
• Knows how to use the token
Server Perspective
• Stateless & Client Agnostic
• If Client Sends Token
• I know how to interpret
• I know how to create ...
Server Perspective
• Stateless & Client Agnostic
• If Client Sends Token
• I know how to interpret
• I know how to create ...
Token Creation (our example)
1:1449354972621
base 64 encoded to
MToxNDQ5MzU0OTcyNjIx
Token Version Last Event Result Creat...
What we’ve covered
Synchronizing
Data
Data Format & Protocol
Efficiency
Security
Synchronizing
Data
Data Format & Protocol
Efficiency
Security
• Privacy
• Integrity & Trust
HTTPS - Server SSL
Scenario Goals
• Clients want to know they’re talking to the real server
• Data transferred must be kep...
HTTPS Overview
1. Client requests protected resource
2. Server presents certificate
3. Is this certificate valid, do I trust...
HTTPS - Mutual SSL
Scenario Goals
• Clients want to know they’re talking to the real server
• Data transferred must be kep...
HTTPS Overview
1. Client requests protected resource
2. Server presents certificate
3. Is this certificate valid, do I trust...
HTTPS - Mutual SSL Overview
1. Client requests protected resource
2. Server presents certificate
3. Is this certificate vali...
What we Covered
Synchronizing
Data
Data Format & Protocol
Efficiency
Security
• Privacy
• Integrity & Trust
• Authenticatio...
Authentication
Basic Auth
• Username:Password concatenated with a :

Base 64 Encoded and put into Header like this…



Aut...
Authentication
Client Certificate
• Client issued an SSL Certificates which can contain user identifiable
information.
• Clie...
Authorization
• User - What does the user have access to do.
• Application - What information does the user want to
share ...
User Authorization w/ Roles
Users mapped to Roles
@RolesAllowed(["ROLE_CLIENT"])

class EventController {
...
@RolesAllowe...
Authorization
• User - What does the user have access to do.
• Application - What information does the user want to
share ...
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application
(e.g. Shutterfly)
Facebook
1. User signs up with Shu...
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application
(e.g. Shutterfly)
Facebook
1. User signs up with Shu...
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application
(e.g. Shutterfly)
Facebook
1. User signs up with Shu...
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application
(e.g. Shutterfly)
Facebook
1. User signs up with Shu...
Actor Roles
• Resource Owner - Owner of the data (e.g. user)
• Resource Server - Server which has the resource owners data...
Shutterfly Example Actors
Client
ex Shutterfly
Resource Server
Authorization Server
Identity Provider
ex. Facebook
Resource ...
Shutterfly Example - Registration
Client
ex Shutterfly
Resource Server
Authorization Server
Identity Provider
ex. Facebook1....
Key Terms
• Client Id & Client Secret - Given to the client upon registering with
the authorization server
• Access Token ...
Grant Types
• Authorization Code - Optimized for web clients which can
maintain the confidentiality of their client secret
...
Grant Types
• Authorization Code - Optimized for web clients which can
maintain the confidentiality of their client secret
...
Grant Types
• Authorization Code - Optimized for web clients which can
maintain the confidentiality of their client secret
...
Grant Types
• Authorization Code - Optimized for web clients which can
maintain the confidentiality of their client secret
...
Resource Owner Password Credentials Grant
Authorization Server
Identity Provider
Resource Server
ex Facebookex Shutterfly
1...
Example Application
Android Client
Login Register Find Events
Resource Owner Password Credentials Grant
Authorization Server
Identity Provider
Resource Server
ex Facebookex Shutterfly
1...
Resource Owner Password Credentials Grant
Authorization Server
Identity Provider
Resource Server
Client
Event ServiceEvent...
Event API
URI Method Body (JSON) Response
/register POST Registration Cmd Registration Cmd
/login POST Login Cmd OAuth Tok...
Event API
URI Method Body (JSON) Response
/register POST Registration Cmd Registration Cmd
/login POST Login Cmd OAuth Tok...
Login
• User login to get a token
POST https://localhost:8443/login
Content-Type: application/json
{
"username": "joec123"...
Token Via Resource Owner Password Credentials
• User Specific Access Token
{
"access_token": "54642d51-1fea-4309-a245-dcc43...
Login
• User login to get a token
HTTP 200 - Ok
{
"access_token": "54642d51-1fea-4309-a245-dcc43ffd57ac",
"token_type": "b...
Event API
URI Method Body (JSON) Response
/register POST Registration Cmd Registration Cmd
/login POST Login Cmd OAuth Tok...
Securing Resources
• Resources secured by url pattern match
class OAuth2ServerConfiguration {
public void configure(Resour...
Database Schema
On First Install
1. Add the event api to the oauth_client_details table.
2. Add ROLE_ADMIN, ROLE_CLIENT to the 

security_...
What we Covered
Synchronizing
Data
Data Format & Protocol
Efficiency
Security
• Privacy
• Integrity & Trust
• Authenticatio...
Resources
• Sample Code
• Server - https://github.com/ericmaxwell2003/grailsEventService
• Android - https://github.com/er...
Questions
Upcoming SlideShare
Loading in …5
×

Data Synchronization Patterns in Mobile Application Design

6,748 views

Published on

Data synchronization and offline capabilities are key to creating successful mobile applications and there are many factors to consider.
– What data format should you use?
– How do you manage security?
– How do you efficiently manage syncing data to hundreds of applications independently?
In this session, you’ll learn about various factors that drive answers to these questions. You’ll also learn from live code and interactive demonstrations how to use SSL and OAUTH2 to securely synchronize JSON data with a remote REST service and how to use synchronization tokens to efficiently keep your clients up to date. There will be client examples included for both the iOS and Android platforms, but you’ll be able to apply these concepts to any client, regardless of your platform.

Published in: Software
  • Get access to 16,000 woodworking plans, Download 50 FREE Plans... ◆◆◆ http://t.cn/A6hKwqcb
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ♥♥♥ http://bit.ly/39mQKz3 ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Data Synchronization Patterns in Mobile Application Design

  1. 1. Data Synchronization Patterns in Mobile Application Design Eric Maxwell Credible Software
  2. 2. What to Expect Synchronizing Data Data Format & Protocol Efficiency Security • Privacy • Integrity & Trust • Authentication • Authorization
  3. 3. Example App • Paid subscription application • Ohio’s Premier Events • Users can see events but not update • Admin can update events
  4. 4. Android Client Login Register Find Events
  5. 5. iOS Client Login Register Find Events
  6. 6. Data Format & Protocol Choice Synchronizing Data Data Format & Protocol
  7. 7. Open Ecosystem • Exposing resources to public 3rd party clients (ex. Facebook)
  8. 8. Closed Ecosystem • Exposing resources to clients that you also control
  9. 9. Which approach is best?
  10. 10. Key Questions • What do existing systems & data look like in my organization? • Is it vitally important that I have transaction management across various service calls? • Do I have any other security, service discovery, delivery reliability requirements? • How important is bandwidth? • Are most of my clients & servers speaking the same language?
  11. 11. RPC vs SOAP vs REST https://dzone.com/articles/api-best-practices-plan-your
  12. 12. Examples https://myrestservice.com/api/events/37/registrations/128
  13. 13. Examples https://myrestservice.com/api/events/37/registrations/128 URI
  14. 14. Examples https://myrestservice.com/api/events/37/registrations/128 Nouns
  15. 15. Examples https://myrestservice.com/api/events/37/registrations/128 Nouns Verbs tell what we are doing
  16. 16. Examples https://myrestservice.com/api/events/37/registrations/128 Depends on the verb HTTP METHOD (verb) ACTION GET Get registration 128 that belongs to event 37 POST Create a new registration for event 37 (in this case the 128 would be omitted) PUT Update registration 128 with new data DELETE Delete registration 128
  17. 17. Searching /api/events HTTP GET /api/events?type=conference Find All Find All Events of type ‘conference’
  18. 18. What we’ve Covered Synchronizing Data Data Format & Protocol
  19. 19. Efficiency Synchronizing Data Data Format & Protocol Efficiency
  20. 20. Always use compression As simple as adding the following to your application.yml server:
 tomcat:
 compression: on
 compressableMimeTypes: application/json,application/xml,text/html,text/xml,text/plain And saves you exponentially in data transfer with JSON.
  21. 21. Searching /api/events HTTP GET /api/events?type=conference Find All Find All Events of type ‘conference’ What if we want only want new Events since the last fetch?
  22. 22. Synchronization Tokens /api/events?after=b72cef Find All Events after this ‘token’ Sync tokens act as a bookmark for new fetches
  23. 23. Synchronization Tokens in Action 1. HTTP GET /api/events?after=
  24. 24. Synchronization Tokens in Action 1. HTTP GET /api/events?after= 2. Server Responds with all events & token
  25. 25. Synchronization Tokens in Action 1. HTTP GET /api/events?after= 2. Server Responds with all events & token 3. HTTP GET /api/events?after=MToxN
  26. 26. Synchronization Tokens in Action 1. HTTP GET /api/events?after= 4. Server Responds with events after token 2. Server Responds with all events & token 3. HTTP GET /api/events?after=MToxN
  27. 27. Client Perspective • Unaware of Token Meaning • Knows how to use the token
  28. 28. Client Perspective • Unaware of Token Meaning • Knows how to use the token
  29. 29. Server Perspective • Stateless & Client Agnostic • If Client Sends Token • I know how to interpret • I know how to create tokens
  30. 30. Server Perspective • Stateless & Client Agnostic • If Client Sends Token • I know how to interpret • I know how to create tokens
  31. 31. Token Creation (our example) 1:1449354972621 base 64 encoded to MToxNDQ5MzU0OTcyNjIx Token Version Last Event Result Creation Date id summary other columns date_created 123 Codemash … 2016-01-05T08:00:00Z
  32. 32. What we’ve covered Synchronizing Data Data Format & Protocol Efficiency
  33. 33. Security Synchronizing Data Data Format & Protocol Efficiency Security • Privacy • Integrity & Trust
  34. 34. HTTPS - Server SSL Scenario Goals • Clients want to know they’re talking to the real server • Data transferred must be kept secret
  35. 35. HTTPS Overview 1. Client requests protected resource 2. Server presents certificate 3. Is this certificate valid, do I trust it? 5. Subsequent messages are encrypted/decrypted at 
 each end using an agreed symmetric algorithm and key. 4. Client & Server complete SSL handshaking process
  36. 36. HTTPS - Mutual SSL Scenario Goals • Clients want to know they’re talking to the real server • Data transferred must be kept secret • Server wants to know they’re talking to a valid client and user.
  37. 37. HTTPS Overview 1. Client requests protected resource 2. Server presents certificate 3. Is this certificate valid, do I trust it? 5. Subsequent messages are encrypted/decrypted at 
 each end using an agreed symmetric algorithm and key. 4. Client & Server complete SSL handshaking process
  38. 38. HTTPS - Mutual SSL Overview 1. Client requests protected resource 2. Server presents certificate 3. Is this certificate valid, do I trust it? 7. Subsequent messages are encrypted/decrypted at 
 each end using an agreed symmetric algorithm and key. 6. Client & Server complete SSL handshaking process 5. Is this certificate valid, do I trust it? 4. Client presents certificate
  39. 39. What we Covered Synchronizing Data Data Format & Protocol Efficiency Security • Privacy • Integrity & Trust • Authentication • Authorization
  40. 40. Authentication Basic Auth • Username:Password concatenated with a :
 Base 64 Encoded and put into Header like this…
 
 Authorization: Basic dGVzdFVzZXI6bXlQYXNz
  41. 41. Authentication Client Certificate • Client issued an SSL Certificates which can contain user identifiable information. • Clients send this certificate information to the server which then validates it against a list of trusted client certs.
  42. 42. Authorization • User - What does the user have access to do. • Application - What information does the user want to share with us or allow us to do on their behalf
  43. 43. User Authorization w/ Roles Users mapped to Roles @RolesAllowed(["ROLE_CLIENT"])
 class EventController { ... @RolesAllowed([“ROLE_ADMIN"]) void save() {} ... } Resources Secured by Role
  44. 44. Authorization • User - What does the user have access to do. • Application - What information does the user want to share with us or allow us to do on their behalf
  45. 45. Application Authorization w/ OAuth 2.0 OAUTH 2.0 3rd Party Application (e.g. Shutterfly) Facebook 1. User signs up with Shutterfly 2. Shutterfly gives user option to load their FB photos. 3. May also offer option to use FB to login to Shutterfly, thereby not needing a separate Shutterfly login. 4. User decides to do this, so they click a button during Shutterfly registration. 5. User is sent to FB to authenticate and authorize Shutterfly to access their photos. 6. User is sent back to Shutterfly and Shutterfly can now access those photos. User
  46. 46. Application Authorization w/ OAuth 2.0 OAUTH 2.0 3rd Party Application (e.g. Shutterfly) Facebook 1. User signs up with Shutterfly 2. Shutterfly gives user option to load their FB photos. 3. May also offer option to use FB to login to Shutterfly, thereby not needing a separate Shutterfly login. 4. User decides to do this, so they click a button during Shutterfly registration. 5. User is sent to FB to authenticate and authorize Shutterfly to access their photos. 6. User is sent back to Shutterfly and Shutterfly can now access those photos. User
  47. 47. Application Authorization w/ OAuth 2.0 OAUTH 2.0 3rd Party Application (e.g. Shutterfly) Facebook 1. User signs up with Shutterfly 2. Shutterfly gives user option to load their FB photos. 3. May also offer option to use FB to login to Shutterfly, thereby not needing a separate Shutterfly login. 4. User decides to do this, so they click a button during Shutterfly registration. 5. User is sent to FB to authenticate and authorize Shutterfly to access their photos. 6. User is sent back to Shutterfly and Shutterfly can now access those photos. User
  48. 48. Application Authorization w/ OAuth 2.0 OAUTH 2.0 3rd Party Application (e.g. Shutterfly) Facebook 1. User signs up with Shutterfly 2. Shutterfly gives user option to load their FB photos. 3. May also offer option to use FB to login to Shutterfly, thereby not needing a separate Shutterfly login. 4. User decides to do this, so they click a button during Shutterfly registration. 5. User is sent to FB to authenticate and authorize Shutterfly to access their photos. 6. User is sent back to Shutterfly and Shutterfly can now access those photos. User
  49. 49. Actor Roles • Resource Owner - Owner of the data (e.g. user) • Resource Server - Server which has the resource owners data. • Client - The application or service which wants to access the resource owners data. • Authorization Server - The server which authorizes access to the protected resources after the owner has authenticated given consent. • Identity Provider (IDP) - When OAuth 2 is used for authentication, the identity provider validates user credentials
  50. 50. Shutterfly Example Actors Client ex Shutterfly Resource Server Authorization Server Identity Provider ex. Facebook Resource Owner ex. User
  51. 51. Shutterfly Example - Registration Client ex Shutterfly Resource Server Authorization Server Identity Provider ex. Facebook1. Register 2. Client Id & Secret sent to client
  52. 52. Key Terms • Client Id & Client Secret - Given to the client upon registering with the authorization server • Access Token - Created by the authorization server after the resource owner has authenticated and given permission for the client to access their data • Scope - Defined by the resource server, it indicates what the client is authorized to do on the users behalf. It’s associated with an access token
 (ex: public_profile, publish_actions) • Grant Type - Different ways to get an access token. This will often guide the flow or interaction between the actors
  53. 53. Grant Types • Authorization Code - Optimized for web clients which can maintain the confidentiality of their client secret • Implicit - Optimized for public clients that cannot secure their client secret. Common to JavaScript apps, running in a browser. • Client Credentials - Provides application level (non user specific) access to the resource server. • Resource Owner Password Credentials - Optimized for cases where there is a trust relationship between the authorization server and the client. A thick client on a smart phone or desktop for example.
  54. 54. Grant Types • Authorization Code - Optimized for web clients which can maintain the confidentiality of their client secret • Implicit - Optimized for public clients that cannot secure their client secret. Common to JavaScript apps, running in a browser. • Client Credentials - Provides application level (non user specific) access to the resource server. • Resource Owner Password Credentials - Optimized for cases where there is a trust relationship between the authorization server and the client. A thick client on a smart phone or desktop for example.
  55. 55. Grant Types • Authorization Code - Optimized for web clients which can maintain the confidentiality of their client secret • Implicit - Optimized for public clients that cannot secure their client secret. Common to JavaScript apps, running in a browser. • Client Credentials - Provides application level (non user specific) access to the resource server. • Resource Owner Password Credentials - Optimized for cases where there is a trust relationship between the authorization server and the client. A thick client on a smart phone or desktop for example.
  56. 56. Grant Types • Authorization Code - Optimized for web clients which can maintain the confidentiality of their client secret • Implicit - Optimized for public clients that cannot secure their client secret. Common to JavaScript apps, running in a browser. • Client Credentials - Provides application level (non user specific) access to the resource server. • Resource Owner Password Credentials - Optimized for cases where there is a trust relationship between the authorization server and the client. A thick client on a smart phone or desktop for example.
  57. 57. Resource Owner Password Credentials Grant Authorization Server Identity Provider Resource Server ex Facebookex Shutterfly 1. Request access token for user with: 1. client_id / secret 2. username, password 2. Access token 4. Access token 5. Resources Client
  58. 58. Example Application
  59. 59. Android Client Login Register Find Events
  60. 60. Resource Owner Password Credentials Grant Authorization Server Identity Provider Resource Server ex Facebookex Shutterfly 1. Request access token for user with: 1. client_id / secret 2. username, password 2. Access token 4. Access token 5. Resources Client
  61. 61. Resource Owner Password Credentials Grant Authorization Server Identity Provider Resource Server Client Event ServiceEvent Client App Authenticate Access Resources w/ Token
  62. 62. Event API URI Method Body (JSON) Response /register POST Registration Cmd Registration Cmd /login POST Login Cmd OAuth Token /events/{id} GET n/a Event /events POST Event n/a /events[?syncToken=token] GET n/a List<Event>
  63. 63. Event API URI Method Body (JSON) Response /register POST Registration Cmd Registration Cmd /login POST Login Cmd OAuth Token /events/{id} GET n/a Event /events POST Event n/a /events[?syncToken=token] GET n/a List<Event>
  64. 64. Login • User login to get a token POST https://localhost:8443/login Content-Type: application/json { "username": "joec123", "password": “secretPassword” } 1. Send an /oauth/token request with the appropriate information for a grant_type of password
  65. 65. Token Via Resource Owner Password Credentials • User Specific Access Token { "access_token": "54642d51-1fea-4309-a245-dcc43ffd57ac", "token_type": "bearer", "expires_in": 25222, "scope": "read write" } Success Failure { "timestamp": 1449367453794, "status": 401, "error": "Unauthorized", "message": "Bad credentials", "path": "/oauth/token" } POST https://localhost:8443/oauth/token Authorization: Basic MDgyNDBiNGQtMDlmOS00NGZiLTg4ZjUtM2Q2ODIxZmUyOTIzOjZmMjMxMTA1LWZhZDQtNGFhNC05NTgxLTE4ZDVmNDhlYzgxMA== Accept: application/json Cache-Control: no-cache Content-Type: application/x-www-form-urlencoded username=joec123 password=secretPassword grant_type=password scope=read+write Where the Basic Auth token is comprised of the client_id <== Username client_secret <== Password
  66. 66. Login • User login to get a token HTTP 200 - Ok { "access_token": "54642d51-1fea-4309-a245-dcc43ffd57ac", "token_type": "bearer", "expires_in": 25222, "scope": "read write" } POST https://localhost:8443/login Content-Type: application/json { "username": "joec123", "password": “secretPassword” } • Successful Response 1. Send an /oauth/token request with the appropriate information for a grant_type of password 2. Return response to user
  67. 67. Event API URI Method Body (JSON) Response /register POST Registration Cmd Registration Cmd /login POST Login Cmd OAuth Token /events/{id} GET n/a Event /events POST Event n/a /events[?syncToken=token] GET n/a List<Event>
  68. 68. Securing Resources • Resources secured by url pattern match class OAuth2ServerConfiguration { public void configure(ResourceServerSecurityConfigurer resources) {
 resources
 .resourceId('event-api')
 }
 
 public void configure(HttpSecurity http) throws Exception {
 http
 .authorizeRequests()
 .antMatchers("/register", "/login").permitAll()
 .anyRequest().authenticated()
 }
 } @RolesAllowed(["ROLE_CLIENT"])
 class EventController { ... } • Authorization based on role
  69. 69. Database Schema
  70. 70. On First Install 1. Add the event api to the oauth_client_details table. 2. Add ROLE_ADMIN, ROLE_CLIENT to the 
 security_role table. 3. Add an admin user and associate with all roles.
  71. 71. What we Covered Synchronizing Data Data Format & Protocol Efficiency Security • Privacy • Integrity & Trust • Authentication • Authorization
  72. 72. Resources • Sample Code • Server - https://github.com/ericmaxwell2003/grailsEventService • Android - https://github.com/ericmaxwell2003/ androidEventClientApp • iOS - https://github.com/ericmaxwell2003/iosEventClientApp • OAuth Grant Types & Flows - http://oauthlib.readthedocs.org/ en/latest/oauth2/grants/grants.html • Credible Software - http://credible.software
  73. 73. Questions

×