How APIs Can Be Secured in Mobile Environments

Shan - Director, Mobile Architecture

About the PresenterShan 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

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

Mobile First StrategyDesign products for mobile phones before desktop and laptop computers.

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)

Computer

6

EmployeesManagers

Owners

Customers Suppliers

Shareholders

Productivity Risk

7

EmployeesManagers Owners Customers Suppliers Shareholders

?

Mobile  App  Development

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

9

Native features and UX Performance Code Base Availability - (Developer) Distribution

What  to  choose  ?  

10

Native Mobile Application

iOS - Obj-C, Swift Android - Java

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

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

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

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>

interface

http://<domain>/hr/getEmployeeshttp://<domain>/hr/Employeeshttp://<domain>/hr/Employees.asmx

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

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

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" } ] } ]}

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

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

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

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.

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.

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

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:qop:HA2)

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

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.

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

Mutual  AuthenticationDifficult and complicated to implement

More secured

27

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

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.

Authorization  Code

30

Register your app and get the clientID and clientSecretResource 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

12

ClientSecret

AccessToken

Authorization code

Implicit

31

Register your app and get the clientID , no secret is generatedResource 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

2AccessToken

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

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.

Client Credentials Grant Type

34

Resource OwnerMobile 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

๏ Login Screen (Responsive Web)

๏ Authorization Code (Storing clientID,clientSecret)

๏ Implicit (Token expires , need to login every time)

35

Issues for Mobile Apps

What  is  this  Access  Token  ?

36

A random number A random string A UUID

Storing  the  Token

37

Android - SharedPreferences iOS - Keychain

OpenID  ConnectOpenID 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

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 introducedto 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

WSO2  API  ManagerWSO2  Identity  Server

WSO2  API  Manager

41

Gregory Peck

Gladia Soronika

Ganesh Guru

Michelle Sharapova

42

43

44

45

46

47

WSO2 - IdP Proxy Mobile App

48

Two components SDK IdPProxy Mobile App (iOS,Android)

It provides API security SSO for Native Mobile Apps

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

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

Three Application AZone eBuy IdPProxy

52

Open AZone App

1 2 3 4 5

53

1 2 3

Questions1. 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

Contact  us  !