Data Synchronization Patterns in Mobile Application Design

Data Synchronization Patterns in
Mobile Application Design
Eric Maxwell

Credible Software

What to Expect
Synchronizing
Data
Data Format & Protocol
Efﬁciency
Security
• Privacy
• Integrity & Trust
• Authentication
• Authorization

Example App
• Paid subscription application
• Ohio’s Premier Events
• Users can see events but not update
• Admin can update events

Android Client
Login Register Find Events

iOS Client
Login Register Find Events

Data Format & Protocol Choice
Synchronizing
Data

Open Ecosystem
• Exposing resources to public 3rd party clients (ex. Facebook)

Closed Ecosystem
• Exposing resources to clients that you also control

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?

RPC vs SOAP vs REST
https://dzone.com/articles/api-best-practices-plan-your

Examples
https://myrestservice.com/api/events/37/registrations/128

Examples
URI

Examples
Nouns

Examples
Nouns
Verbs tell what we are doing

Examples
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

Searching
/api/events
HTTP GET
/api/events?type=conference
Find All
Find All Events of type ‘conference’

What we’ve Covered
Synchronizing
Data

Efﬁciency
Synchronizing
Data
Efﬁciency

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.

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?

Synchronization Tokens
/api/events?after=b72cef Find All Events after this ‘token’
Sync tokens act as a bookmark for new fetches

Synchronization Tokens in Action
1. HTTP GET /api/events?after=

2. Server Responds with all events & token

3. HTTP GET /api/events?after=MToxN

4. Server Responds with events after token
3. HTTP GET /api/events?after=MToxN

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 tokens

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

What we’ve covered
Synchronizing
Data
Efﬁciency

Security
Synchronizing
Data
Efﬁciency
Security
• Privacy

HTTPS - Server SSL
Scenario Goals
• Clients want to know they’re talking to the real server
• Data transferred must be kept secret

HTTPS Overview
1. Client requests protected resource
2. Server presents certiﬁcate
3. Is this certiﬁcate 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

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.

HTTPS - Mutual SSL Overview
1. Client requests protected resource
2. Server presents certiﬁcate
7. Subsequent messages are encrypted/decrypted at  
each end using an agreed symmetric algorithm and key.
6. Client & Server complete SSL handshaking process
4. Client presents certiﬁcate

What we Covered
Synchronizing
Data
Efﬁciency
Security
• Privacy
• Authentication
• Authorization

Authentication
Basic Auth
• Username:Password concatenated with a : 
Base 64 Encoded and put into Header like this… 
 
Authorization: Basic dGVzdFVzZXI6bXlQYXNz

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.

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

User Authorization w/ Roles
Users mapped to Roles
@RolesAllowed(["ROLE_CLIENT"]) 
class EventController {
...
@RolesAllowed([“ROLE_ADMIN"])
void save() {}
...
}
Resources Secured by Role

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

OAUTH 2.0
(e.g. Shutterfly)
Facebook
photos.
3. May also offer option to use FB to login to
Shutterfly login.
User

OAUTH 2.0
(e.g. Shutterfly)
Facebook
photos.
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.
User

OAUTH 2.0
(e.g. Shutterfly)
Facebook
photos.
Shutterfly login.
6. User is sent back to Shutterfly and Shutterfly
can now access those photos.
User

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

Shutterﬂy Example Actors
Client
ex Shutterﬂy
Resource Server
Authorization Server
Identity Provider
ex. Facebook
Resource Owner
ex. User

Shutterﬂy Example - Registration
Client
ex Shutterﬂy
Resource Server
Identity Provider
ex. Facebook1. Register 2. Client Id & Secret
sent to client

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

Grant Types
• Authorization Code - Optimized for web clients which can
maintain the conﬁdentiality 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
speciﬁc) 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.

Resource Owner Password Credentials Grant
Identity Provider
Resource Server
ex Facebookex Shutterﬂy
1. Request access token for user with:
1. client_id / secret
2. username, password
2. Access token
4. Access token
5. Resources
Client

Resource Owner Password Credentials Grant
Identity Provider
Resource Server
Client
Event ServiceEvent Client App
Authenticate
Access Resources w/ Token

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>

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

Token Via Resource Owner Password Credentials
• User Speciﬁc 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

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

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

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.

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

Data Synchronization Patterns in Mobile Application Design

More Related Content

What's hot

Similar to Data Synchronization Patterns in Mobile Application Design

Recently uploaded

Data Synchronization Patterns in Mobile Application Design