Data Synchronization Patterns in Mobile Application Design

Data Synchronization Patterns in Mobile Application Design

Eric MaxwellCredible Software

What to Expect

Synchronizing Data

Data Format & Protocol

Efficiency

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


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

Which approach is best?

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

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


Efficiency

Synchronizing Data


Efficiency

Always use compressionAs 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


Efficiency

Security

Synchronizing Data


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 kept secret

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

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 Overview






HTTPS - Mutual SSL Overview







4. Client presents certificate

What we Covered

Synchronizing Data


Efficiency


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

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

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

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

Shutterfly Example Actors

Client ex Shutterfly

Resource Server Authorization Server

Identity Provider ex. Facebook

Resource Owner ex. User

Shutterfly Example - Registration

Client ex Shutterfly

Resource Server Authorization 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 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.

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

Example Application

Android Client



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


Authorization Server 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 tokenPOST 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 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

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

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>

Securing Resources

• Resources secured by url pattern matchclass 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

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_role table.

3. Add an admin user and associate with all roles.

What we Covered

Synchronizing Data


Efficiency


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

https://github.com/ericmaxwell2003/grailsEventService

https://github.com/ericmaxwell2003/androidEventClientApp

https://github.com/ericmaxwell2003/iosEventClientApp

http://oauthlib.readthedocs.org/en/latest/oauth2/grants/grants.html

http://credible.software

Questions

Data Synchronization Patterns in Mobile Application Design

Software

Transcript of Data Synchronization Patterns in Mobile Application Design