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.
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. RPC vs SOAP vs REST
https://dzone.com/articles/api-best-practices-plan-your
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.
24. Synchronization Tokens in Action
1. HTTP GET /api/events?after=
2. Server Responds with all events & token
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. 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
29. Server Perspective
• Stateless & Client Agnostic
• If Client Sends Token
• I know how to interpret
• I know how to create tokens
30. Server Perspective
• Stateless & Client Agnostic
• If Client Sends Token
• I know how to interpret
• I know how to create tokens
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
34. HTTPS - Server SSL
Scenario Goals
• Clients want to know they’re talking to the real server
• Data transferred must be kept secret
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. 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. 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. 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
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. 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. User Authorization w/ Roles
Users mapped to Roles
@RolesAllowed(["ROLE_CLIENT"])
class EventController {
...
@RolesAllowed([“ROLE_ADMIN"])
void save() {}
...
}
Resources Secured by Role
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. 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. 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. 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. 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. 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. Shutterfly Example Actors
Client
ex Shutterfly
Resource Server
Authorization Server
Identity Provider
ex. Facebook
Resource Owner
ex. User
51. Shutterfly Example - Registration
Client
ex Shutterfly
Resource Server
Authorization Server
Identity Provider
ex. Facebook1. Register 2. Client Id & Secret
sent to client
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. 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. 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. 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. 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. 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
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. Resource Owner Password Credentials Grant
Authorization Server
Identity Provider
Resource Server
Client
Event ServiceEvent Client App
Authenticate
Access Resources w/ Token
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. 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. 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. 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. 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. 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. 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
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.