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": "[email protected]", "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":"[email protected]", "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 !