Date post: | 12-Apr-2017 |
Category: |
Software |
Upload: | eric-maxwell |
View: | 2,023 times |
Download: | 2 times |
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
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 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
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 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
Data Format & Protocol
Efficiency
Synchronizing Data
Data Format & Protocol
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=
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 /api/events?after=MToxN
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
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 tokens
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
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 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
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 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
What we Covered
Synchronizing Data
Data Format & Protocol
Efficiency
Security • Privacy • Integrity & Trust • 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
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)
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
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application (e.g. Shutterfly)
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
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application (e.g. Shutterfly)
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
Application Authorization w/ OAuth 2.0
OAUTH 2.0
3rd Party Application (e.g. Shutterfly)
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.
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.
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.
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
Login Register Find Events
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
Resource Owner Password Credentials Grant
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>
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
Data Format & Protocol
Efficiency
Security • Privacy • Integrity & Trust • Authentication • Authorization
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
Questions