To view recording of this webinar please use below URL: http://wso2.com/library/webinars/2015/08/how-apis-can-be-secured-in-mobile-environments/ In this session, Shan, director of mobile architecture at WSO2 will discuss: What makes mobile API authentication different from traditional API authentication Best practices for implementing mobile API security What WSO2 API Manager provides for mobile developers

1. How APIs Can Be Secured in Mobile Environments
Shan - Director, Mobile Architecture

2. About the Presenter
Shan specializes in mobile technology with over 10 years experience in that field.
He has a strong background in telecommunication software development and is a
hardcore coder in Android and iOS platforms.
Prior to joining WSO2Mobile, he was working as the CTO/Director of Microimage Mobile
Media for almost 16 years.
He played a key role in engineering products where Microimage has won many local &
international awards which includes winning the Inaugural GSMA Asia Mobile Innovation
Award, Commendation from GSMA at the Barcelona World Awards in 2007, Asia Pacific
ICT Awards (APICTA)
Lecturer at Cicra campus (Executive MSc in Information Security)
Hobbyist (Arduino/RPi/ Wearable Devices)

3. 3
Web Service Web API
SOAP REST
iOS Android Windows
WSDLUDDI
JAX-WSJAX-RS WCF CXFJersey RestEasyRestlet
ProtocolStandards Framework
XML-RPCPOXML
Http Https SMTP TCP/IP
SSO
OAuthOpenID Connect
WADL API

4. 4
Mobile First Strategy
Design products for mobile phones before desktop and laptop
computers.

5. Rise of the Mobile-First Enterprise Apps
5
• Managers, executives and other decision makers spend
huge amounts of time outside of their offices
• Mobile is how they stay connected to their businesses.
• Stay connected to data 24/7 (data anytime, anywhere)

6. Computer
6
Employees
Managers
Owners
Customers Suppliers
Shareholders
Productivity Risk

7. 7
EmployeesManagers Owners Customers Suppliers Shareholders
?

8. Mobile
App
Development
1.Responsive Web
2.Hybrid Web
3.Mobile Web
4.Hybrid Native
5.Native Apps

9. 9
Native features and UX
Performance
Code Base
Availability - (Developer)
Distribution
What
to
choose
?

10. 10
Native Mobile Application
iOS - Obj-C, Swift
Android - Java

11. 11
I
n
t
e
r
f
a
c
e
Web API
API describes
what functionality is available
how it must be used
what formats it will accept as input or return as output

12. How
API’s
are
exposed
12
• COM objects
• DLL and .H files in C/C++ programming language
• JAR files
• RMI in Java
• XML over HTTP
• JSON over HTTP

13. WebAPI
Vs
WebService
13
Does not define the how data is sent
over the network
Involves sending data over a network
All APIs are not Web services. All Web services are APIs
API may use any style for
communication
Three styles of use: SOAP, REST and
XML-RPC for communication
API consists of a complete set of rules
and specifications for a software program
to follow in order to facilitate interaction.
A Web service might not contain a
complete set of specifications and
sometimes might not be able to perform
all the tasks that may be possible from a
complete API.

14. 14
Gregory Peck
Gladia Soronika
Ganesh Guru
Michelle Sharapova
POST /webservices/hr/employees.asmx HTTP/1.1
Host: www.w3schools.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<GetEmployees xmlns="http://www.w3schools.com/webservices/">
</GetEmployees>
</soap12:Body>
</soap12:Envelope>
i
n
t
e
r
f
a
c
e
http://<domain>/hr/getEmployees
http://<domain>/hr/Employees
http://<domain>/hr/Employees.asmx

15. SOAP
• provide a way to build and invoke a hosted API in a language- and platform-neutral manner.
• message from one end to the other is passed as an XML payload.
• very structured and is backed by a large number of specifications.
• request/response protocol between the client and the server is defined in the SOAP
specification.
• service is defined in Web Services Description Language (WSDL).
• WS-Security, WS-Trust, and WS-Federation specifications provides security
• WS-Policy provides a framework to build quality-of-service expressions
• WS-SecurityPolicy defines the security requirements of a SOAP service in a standard way, built
on top of the WS-Policy framework.
• highly decoupled, standardized, and governed based on policies, preferred way build a
service-oriented architecture (SOA)
15
Popularity has declined
• complexity of the WS-* standards.
• many ambiguities arose among different implementation stacks
Web Services Interoperability (WS-I) organization came up with the Basic Profile for
web services

16. REST
16
• based on the rule set defined in the HTTP specification
• not restricted to XML format (can be plain text, JSON, and also XML)
• protocol independent
• uses the security and authentication of HTTP
• REST is not REST without HATEOAS (client only knows the entry point URI and the
resources are supposed to return links)
• service is defined in Web Application Description Language (WADL).

17. 17
HATEOAS - Hypermedia as the Engine of Application State
{
"links": [
{
"rel": "self",
"href": "http://localhost:8080/customers"
}
],
"content": [
{
"fullName": "Matthews, Dave",
"email": "dave@dmband.com",
"links": [
{
"rel": "self",
"href": "http://localhost:8080/customers/1"
}
]
}
]
}

18. Designing
WebAPI
18
• Web API should be stateless
(no session state, cookies, or server-side values)
Adding state adds complexity and limits scalability
• Endpoints of the API should be exposed through SSL by default
• User credentials should never be passed as part an API call
GET /employees?userid=greg&password=1234
- still visible in any logs on the Web server (even passed in header)
- credentials can be corporate accounts used for other systems
- lifetime (until the password is changed)
• some APIs use an application key or some other token derived from
a HMAC algorithm
- if the key is exposed, it can be difficult to revoke. Key embedded in a mobile app

19. Designing
Rest
API
19
Correct use of REST is about nouns, not verbs
GET /GetAccountBalance?account_id=1234
GET /accounts/1234
GET /accounts?fields=id,name&sort=id&limit=100&offset=50
HTTP VERBS together with nouns or entities in the URL that represent the data
you are exposing
GET List Account /accounts/1234
PUT Update Account /accounts/1234
POST Add Account /accounts/1234
DELETE Delete Account /accounts/1234

20. API
Security
20
Most Basic form of API Authentication
Simple for API Services developer and the API Consumer
HTTP Basic Authentication
HTTP Digest Authentication
Mutual Authentication
OAuth2.0
OpenId Connect

21. HTTP
Basic
Authentication
21
How it Works ?
If an API is HTTP Basic Authenticated :
Client Browser sends
GET /hr/employee/2 HTTP/1.1
Host: www.wso2.com
Server Reply
HTTP/1.1 401 Access Denied
WWW-Authenticate: Basic realm=“wso2.com"
Content-Length: 0
Client Browser sends
GET /hr/employee/2 HTTP/1.1
Host: www.wso2.com
Authorization: Basic aHR0cHdhdGNoOmY=
www.wso2.com/hr/employee/2
www.wso2.com:80
Base64Encode(username:password)
A string to be displayed to users so they know which username and password to use. This string should contain at
least the name of the host performing the authentication and may additionally indicate the collection of users who
may have access.

22. HTTP
Basic
Authentication
-­‐
Mobile
Apps
22
• username and password
• Header - Authorization: Basic aHR0cHdhdGNoOmY=
• call the API
https://www.wso2.com/hr/employees
https://www.wso2.com/hr/employee/1
• username and password
• Header - Authorization: Basic aHR0cHdhdGNoOmY=
• call the API
How to store the username and password ?
When using the App or Master secret with
Basic Auth, use your App Key as the
username, and the secret as the password.

23. HTTP
Digest
Authentication
23
Client Browser sends
GET /hr/employee/2 HTTP/1.1
Host: www.wso2.com
Server Reply
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="wso2.com", qop="auth",
nonce="1390781967182:c2db4ebb26207f6ed38bb08eeffc7422",
opaque="F5288F4526B8EAFFC4AC79F04CA8A6ED"
Client Browser sends
GET /hr/employee/2 HTTP/1.1
Host: www.wso2.com
Authorization: Digest username="shan", realm=“wso2.com",
nonce=“1390781967182:c2db4ebb26207f6ed38bb08eeffc7422",
uri=“/hr/employee“, cnonce="MTM5MDc4", nc=00000001, qop="auth",
response="f5bfb64ba8596d1b9ad1514702f5a062",
opaque="F5288F4526B8EAFFC4AC79F04CA8A6ED"
realm: A string to be displayed to users so they know
which username and password to use. This
string should contain at least the name of the
host performing the authentication and may
additionally indicate the collection of users who
may have access.
nonce: A server-specified data string, which should be
uniquely generated each time a 401 response is
made. The content of the nonce is
implementation dependent.
opaque: A string of data, specified by the server, that
should be returned by the client unchanged in the
Authorization header of subsequent requests
with URIs in the same protection space (which is
the realm).
qop: The “quality of protection” options applied to the
response by the server. The value auth indicates
authentication while auth-int indicates
authentication with integrity protection.
Refer : www.ietf.org/rfc/rfc2617.txt

24. 24
How
to
calculate
the
Response
in
HTTP
Digest
?
qop = “auth”
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)
qop = “auth-int”
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI:MD5(entityBody))
response=MD5(HA1:nonce:nonceCount:clientNonce:qo
qop is unspecified
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)
Digest calculation is done with two types of data:
security-related data qop = “auth”
message-related data qop = “auth-int”

25. 25
HTTP Basic Authentication HTTP Digest Authentication
Sends credentials in cleartext over the wire Credentials are never sent in cleartext. A digest derived
from the cleartext password is sent over the wire.
Should be used in conjunction with some external security
systems like TLS
Doesn’t depend on transport-level security or external
security systems.
Only performs authentication Can be used to protect the integrity of the message, in
addition to authentication (with qop=auth-int).
User store can store passwords as a salted hash User store should store passwords in cleartext or should
store the hash value of username:password:realm.
• Storing the password in cleartext or the hashed value of username:password:realm in Mobile
Device
• Neither option is safe.
• Recommended is to encrypt and store the hash of username:password:realm.
As a general rule, if servers or proxies don't understand the values of standard headers,will ignore it.

26. Mutual
Authentication
Device presents the login screen
Authentication happens
Device will create the CSR based on the server policy
Service signs the certificate and sends the certificate to
the device
Both way the communication is signed and encrypted
26

27. Mutual
Authentication
Difficult and complicated to implement
More secured
27

28. OAuth
2.0
28
OAuth2 is an excellent protocol for securing API services from
untrusted devices
1.A user opens up your mobile app and is prompted for their username or
email and password.
2.You send a POST request from your mobile app to your API service with
the user’s username or email and password data included
3.You validate the user credentials, and create an access token for the
user that expires after a certain amount of time.
4.You store this access token on the mobile device, treating it like an API
key which lets you access your API service.
5.Once the access token expires and no longer works, you re-prompt the
user for their username or email and password.
6. Can use refresh token to get a new token if expired
Temporary access token
It will expire
Even if stolen only for a specific time period

29. Grant
Types
๏ Authorization
Code
๏ Implicit
(No
client
secret)
๏ Resource
Owner
Password
Credentials
๏ Client
Credentials
29
OAuth clients must be registered with the OAuth
authorization server and obtain a client identifier before
any interactions.

30. Authorization
Code
30
Register your app and get the clientID and clientSecret
Resource Owner User Agent
Web App
Authentication Server Resource Server
1 Redirect happens - https://<domain>/oauth2/authorize?
response_type=code&client_id=0rhQErXIX49svVYoXJGt0DWBuFca&redirect_uri=https://oauth2client.com
Display with Authentication page
Authenticate with your username and password
Ask for confirmation
2 https://oauth2client.com/cb?code=3509530953850395
3 Authorization code is extracted and sent to the Authentication Server to get the Token along with the ClientSecret
POST https://api.oauth2server.com/token
grant_type=authorization_code&
code=AUTH_CODE_HERE&
redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
4.Now you call the API with the Authorization Token
3
4
1
2
ClientSecret
AccessToken
Authorization code

31. Implicit
31
Register your app and get the clientID , no secret is
generated
Resource Owner User Agent
Web App
Authentication Server Resource Server
1 Redirect happens - https://<AuthServer>/oauth?response_type=token
&client_id=CLIENT_ID&redirect_uri=https://oauth2client.com&scope=email
Display with Authentication page
Authenticate with your username and password
Ask for confirmation
2 https://oauth2client.com/#access_token=cac93e1d29e45bf6d84073dbfb460&expires_in=3600
AccessToken is extracted , no refresh token for this
3.Now you call the API with the Access Token for a limited period
3
1
2
AccessToken

32. Implicit
-­‐
Mobile
Native
Apps
32
Resource Owner Mobile App
Authentication Server Resource Server
1 From the web view - https://<AuthServer>/oauth?response_type=token
&client_id=CLIENT_ID&redirect_uri=https://oauth2client.com&scope=email
Display with Authentication page
Authenticate with your username and password
Ask for confirmation
2 https://oauth2client.com/#access_token=cac93e1d29e45bf6d84073dbfb460&expires_in=3600
AccessToken is extracted , no refresh token for this
3.Now you call the API with the Access Token for a limited period from the native code
3
1
2
AccessToken
WebView
Login Page has to support responsive Web

33. Resource Owner Password Credentials
33
Resource Owner Mobile App
Authentication Server Resource Server
1 From the application Pass the clientID clientSecret as Base64 in Authorization header
curl -v -X POST --basic
-u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
-H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8" -k
-d "grant_type=password&
username=admin&password=admin"
https://<AuthServer>/oauth2/token
2 Now you call the API with the Access Token and use the refresh token to get the Access Token if expired
2
AccessToken + Refresh Token
Resource owner must trust the client application.
The Resource Owner Password Credentials grant type was introduced to aid
migration from HTTP Basic Authentication and Digest Authentication to OAuth 2.0.

34. Client Credentials Grant Type
34
Resource Owner
Mobile App
Authentication Server Resource Server
1 From the application Pass the clientID clientSecret as Base64 in Authorization header
curl -v -X POST --basic
-u 0rhQErXIX49svVYoXJGt0DWBuFca:eYOFkL756W8usQaVNgCNkz9C2D0a
-H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8" -k
-d "grant_type=client_credentials" https://<AuthServer>/oauth2/token
2 Now you call the API with the Access Token (Client Credentials grant type doesn’t return a refresh token)
2
AccessToken + Refresh Token
Client itself becomes the resource owner

35. ๏ Login Screen (Responsive Web)
๏ Authorization Code (Storing clientID,clientSecret)
๏ Implicit (Token expires , need to login every time)
35
Issues for Mobile Apps

36. What
is
this
Access
Token
?
36
A random number
A random string
A UUID

37. Storing
the
Token
37
Android - SharedPreferences
iOS - Keychain

38. OpenID
Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
Can verify the identity of the End-User based on the authentication
performed by an Authorization Server
Can obtain basic profile information about the End-User in an
interoperable and REST-like manner
38

39. OpenID
Connect
๏ OpenID Connect was built on
top of OAuth
39
JSON web token (JWT) that transports authenticated user
information from the authorization server to the client
application.
{
"iss":"https://auth.server.com",
"sub":"shan@wso2.org",
"aud":"67jjuyuy7JHk12",
"nonce":"88797jgjg32332",
"exp":1416283970,
"iat":1416281970,
"auth_time":1311280969,
}
iss: The token issuer (authorization server)’s identifier in the format
of an HTTPS URL with no query parameters or URL fragments.
sub: The local identifier of the authenticated user.
aud: The audience of the token. This can be an array of identifiers,
but it must have the
OAuth client ID in it; otherwise the client ID should be added to the
azp parameter.
nonce: This parameter was introduced
to mitigate replay attacks. The authorization server must reject any
request if it finds two requests with the same nonce value. If a
nonce is present in the authorization grant request, then the
authorization server must include the same value in the ID token.
The client application must validate the value of the nonce once it
receives the ID token from the authorization server.
exp: The token-expiration time in seconds from 1970-01-01T0:0:0Z
(UTC). iat: The token-issued time in seconds from
1970-01-01T0:0:0Z (UTC).
auth_time: The time at which the end user authenticates with the
authorization server.

40. 40
WSO2
API
Manager
WSO2
Identity
Server

41. WSO2
API
Manager
41
Gregory Peck
Gladia Soronika
Ganesh Guru
Michelle Sharapova

42. 42

43. 43

44. 44

45. 45

46. 46

47. 47

48. WSO2 - IdP Proxy Mobile App
48
Two components
SDK
IdPProxy Mobile App (iOS,Android)
It provides
API security
SSO for Native Mobile Apps

49. How
to
use
it
?
๏ The developer needs to embed the SDK and add few
lines of code
๏ The end user needs to download the application and
also the IdPProxy Application
49

50. How
it
works
50
6"
• Developer Registers their app in the IS Server
• Gets the clientID and clientSecret for that App
• Uses the IdP proxy SDK and configures the clientID and Secret
• The App invokes the IdP Proxy App with the clientID and other
parameters
• IdP Proxy App displays the login screen to authenticate the
user and passes the Authorization Code to the called App
• The App uses the AuthCode to get the Token which is called
from IdP Proxy SDK .
• After getting the Token the app call any API
• If expired , then the SDK gets the Token again using Refresh
Token

51. 51
Three Application
AZone
eBuy
IdPProxy

52. 52
Open AZone App
1 2 3 4 5

53. 53
1 2 3

54. Questions
1. The app constantly synchronizes with the server via API. How to avoid an user to enter
credentials every time his token is expired ?
2. What about calls I might need to make to our API -prior- to a user authenticating. Do I get a
token using the implicit grant type for these non-authenticated calls?
3. What grant-type to use for mobile Authorization Code or Resource Owner Password
Credentials or Client Credentials or Implicit
4. Can I use self-signed certificate ?
5. Do I need to validate the certificate every time ? How ?
6. Mutual Authentication way ? Is it difficult
7. Storing Tokens in the device Account Manager, KeyChain ?
54

55. Contact
us
!