comparison of jwt and oauth 2.0 authorisation and … · 2020-01-30 · primerjava tehnik jwt in...
TRANSCRIPT
Vid Visočnik
Comparison of JWT and OAuth 2.0 authorisation and authentication techniques in REST services
Primerjava tehnik JWT in oAuth 2.0 za avtorizacijo in avtentikacijo pri uporabi storitev REST
Master thesis
Maribor, Junij 2018
i
Comparison of JWT and OAuth 2.0 authorisation and
authentication techniques in REST services
Primerjava tehnik JWT in oAuth 2.0 za avtorizacijo in avtentikacijo
pri uporabi storitev REST
Master thesis
Student: Vid Visočnik
Student Programme: University Student Programme
Informatics and Technologies of Communication
Mentor: Doc. Dr. Domen Verber
Proofreader: Mrs. Shelagh Hedges
ii
Acknowledgement
I would like to thank my mentors Dr. Domen
Verber and Dr. Paul Baltarejo Sousa sincerely
for their guidance throughout the
dissertation. Furthermore, I would like to
thank my family and friends for supporting
and encouraging me during my studies.
iii
Primerjava tehnik JWT in oAuth 2.0 za avtorizacijo in avtentikacijo
pri uporabi storitev REST
Ključne besede: REST storitve, OAuth 2.0, JWT, žetonska avtentikacija, komunikacijska
varnost, avtorizacija, avtentikacija
UDK: 004.056.523(043.2)
Povzetek
Magistrsko delo se navezuje na področje žetonske avtentikacije in avtorizacije uporabnika
pri uporabi programske opreme, ki za svoje delovanje uporablja spletne storitve razvite na
podlagi arhitekturnega vzorca REST. V samem delu predstavljamo najboljše prakse
razvoja spletnih storitev in raznih odjemalcev, hrambe občutljivih podatkov in vpeljavo
učinkovito varnostne politike tako na transportni oziroma komunikacijski strani kot
aplikacijski strani. V samem delu teoretično opišemo celotno infrastrukturo in protokole
potrebne za delovanje takšnih sistemov ter se poglobimo v samo strukturo žetonske
avtentikacije in avtorizacije uporabnika na trenutno dveh najbolj uporabljenih
tehnologijah oAuth 2.0 in JWT. V samem praktičnem delu smo s pomočjo implementacije
prikazali različne načine uporabe, tok komunikacije in hrambo med samim odjemalcem in
ponudnikom. Tehnološki napredek je skozi novejšo zgodovino dodobra prevetril načine
kako ljudje komuniciramo. Ljudje dandanes komuniciramo več, iz različnih tehnoloških
naprav, omrežij in lokacij. Do podatkov, kot uporabniki, želimo hitro, enostavo in od
kjerkoli. Vse to doprinese, da imamo na eni strani tehnološko različne odjemalce
uporabnikov kot so računalnik, pametna naprava, naprave iz segmenta - internet stvari
(iot), ipd. in na drugi strani ponudnike spletne storitve z dodano vrednostjo, ki želijo
podpreti pridobivanje vseh potrebnih podatkov iz enotnega spletnega vira za vse naštete
segmente. Da bi tehnologija zadostila vsem tem zahtevam so potrebne spremembe tako
na strani arhitekturne zasnovanosti informacijskih sistemov kot tudi spremembe pri
iv
zasnovi omrežij in pristopih shranjevanja podatkov. Če smo še na previsu 2. tisočletja bili
mnenja, da je strežnik tisti, ki je namenjen hrambi stanja odjemalca je danes takšen model
zasnove informacijskih sistemov, za veliko ponudnikov, postal nevzdržen za podporo vseh,
tehnološko neodvisnih, klientov. Skozi razvoj spleta in tehnoloških naprav smo bili tako
priča ogromnim premikom na področju komunikacijske tehnologije in konceptov
komuniciranja med računalniškimi sistemi. Prvotne strukturirane in interoperabilne oblike
prenosa podatkov med dvema informacijskima sistema so bile zasnovane na konceptih
serializacije, ki so bili leta 1990 definirani pod okriljem standard imenovan CORBA.
Evolucija in tehnologija, ki je v spletnih sistemih nadomestila uporabo CORBE je doprinesla
definicija standarda SOAP, ki so ga leta 1998 predstavili Dave Winer, Don Box, Bob
Atkinson, in Mohsen Al-Ghosein. Standard SOAP je definiral protokol izmenjave, način
komunikacije s pomočjo strukturiranega jezika XML in definiciji spletnih končnih točk s
uporabo storitveno definicijske datoteke WSDL. Navkljub prvotno razširjeni uporabi
standarda SOAP se je s poplavo oblačnih storitev uporaba drastično zmanjšala saj format
podatkov v obliki XML povzroči večje količine prenosa podatkov med odjemalcem in
ponudnikom storitve, kar lahko rezultira v vidnih performančnih pribitkih pri komunikaciji.
Težnja po načinu komunikacije, ki omogoča lažjo in hitrejšo spremenljivost na storitveni
strani in ne definira kompleksnih struktur za prenos podatkov je vodila v vedno večjo
uporabo arhitekturnega pristopa za definicijo spletnih končnih točk – REST. REST
arhitekturni pristop je leta 2000 prvič definiral Roy Fielding v svoji doktorski disertaciji z
naslovom »Architectural Styles and the Design of Network-based Software Architectures«.
V doktorski disertaciji je Roy Fielding definiral koncept komunikacije, ki se močno opira na
že obstoječ standard za spletni prenos HTTP hkrati pa definira strogo neodvisno
komunikacijo na način, da noben HTTP zahtevek ne sme biti odvisen od zaporedja
prejšnjih. Neodvisnost zahtevkov in tehnična idempotentnost razvijalcem omogoča, da
lahko svoje zaledne sisteme skalirajo in prilagajo glede na potrebe na način horizontalne
kot tudi vertikalne razteznosti. Implementacija brez stanja posledično privede do novih
konceptov obravnave in ugotavljanja identitete, avtentikacije in avtorizacije uporabnikov.
Uporabniki več ne izmenjajo prijavnih informacij za indikator seje saj bi le to pomenilo
držanje stanja na zalednih sistemih. Takšni pristopi so privedli do novih oblik uporabniške
v
identifikacije, ki jih poznamo kot žetonske tehnike. Žetonska tehnika identifikacije pomeni,
da uporabnik ob izmenjavi pravilnih prijavnih informacij prejme kompaktno, enkodirano,
tekstualno reprezentacijo, ki je digitalno šifrirana in podpisana, ter veljavna le kratek čas.
Odjemalec ob vsakem klicu spletne storitve pripne žeton, ki nosi vse potrebne informacije
o dovoljenosti dostopa do storitvene končne točke kakor tud odjemalca enolično določa.
Na strani spletne storitve se tako ne drži nobenega aplikacijskega stanja ampak se to
stanje prenese na samega odjemalca. S tem ko stanje premaknemo na stran odjemalca
dosežemo, da se na strani spletne storitve sprostijo viri, ki so bili prej namenjeni za
vzdrževanja seje vsakega odjemalca. Trenutno najbolj uporabljeni žetonski tehniki sta
nedvomno JWT in oAuth 2.0. Obe tehniki sta del predlogov za industrijski standard (RFC
6749, RFC 7519). Uporaba žetonskih tehnik nam rešuje mnogo težav s skalabilnostjo
zalednih sistemov. Z uvedbo novih načinov uporabniške identifikacije pa pridobimo sveženj
novih izzivov na katere moramo biti pozorni in jih je potrebno ustrezno nasloviti. Eden
izmed takšnih izzivov je, da iz strežniške avtentikacije in avtorizacije uporabnikov, ki jo
najdemo pri uporabi sejnih protokolov, preidemo na aplikacijsko avtentikacijo in
avtorizacijo, kar pomeni večjo varnostno tveganje saj smo za varnost končnih točk
odgovorni sami. Tako se lahko hitro zgodi, da se zaradi programerske napake ali
malomarnosti ustvari varnostno tveganje politike dostopa do spletnih storitev. Pri uporabi
sejnih protokolov je sprememba avtorizacijske politike dostopa za uporabnika vidna takoj.
Pri žetonskih tehnikah se stanje invalidira šele s potekom kratkoročnega žetona dostopa.
Tudi to nam predstavlja varnostno tveganje saj bi, invalidaciji navkljub, uporabnik še
vedno lahko dostopal do same spletne storitve. Arhitekturni stil REST se za varnost
prenosa močno opira na podležeče standarde HTTPS medtem, ko ima standard SOAP
varnost definirano in specificirano z objavo podležečega standarda WS-Security.
Popularnost uporabe REST kot pristop za definicijo spletnih končnih točk še ne pomeni, da
je standard SOAP toliko slabši. Bistvena razlika med njima vidimo predvsem v manjši
krivuliji potrebnega začetnega učenja, ki je potrebna pri pristopu REST in veliko lažji
prilagodljivosti na same spremembe. Kar je pri pristopu REST slabost lahko najdemo kot
prednost pri standardu SOAP. REST po svojii definiciji nima omogočenega pogodbenega
popisa spletne storitve. Kadar se gre za jasno definirano komunikacijo in izmenjavo
vi
sporočil, kot jih lahko vidimo naprimer na raznih konceptih G2G (Goverment to
goverment) ali strogo definiranih B2B segmentih, nam lahko standard SOAP zelo olajša
delo. V samem magistrskem delu smo se osredotočili na arhitekturni stil REST. Za zaščito
transportnega kanala smo pri razvoju uporabili in konceptualno razložili standard TLS. Za
samo uporanbiško identifikacijo, avtentikacijo in avtorizacijo smo uporabili obe žetonski
tehniki oAuth 2.0 in JWT, ki sta bili namenjeni za omejitev dostopa do spletnih storitev kot
tudi za dostop do uporabnikovih virov na storitvah tretjega vira. Vsi omenjeni koncepti so
bili uporabljeni na prinicpu razvoja mobilne aplikacije namenjene glasbenikom in urejanju
notne literature. Sam razvoj mobilne aplikacije in zalednih sistemov nam je omogočil bolj
podroben vpogled v izzive, ki jih srečujejo programerji med samim načrtovanjem in
razvojem takšnih sistemov. Pri samem razvoju je potrebno upoštevati razne pristope
razvoja tako na storitveni strani kot na strani odjemalca. Problemi, ki jih naslovimo
izhajajo iz samih naslovov izdajanja žetonov, kot tudi njihove hrambe in preklica uporabe.
V kolikor smo poskrbeli za varnost na storitvenem nivoju in ne na nivoju odjemalca se nam
lahko pojavi varnostno tveganje, ki ga tudi kot nadzorniki zalednih sistemov težko
opazimo kot anomalijo v samem sistemu. Skupaj s samo vzpostavitvijo in razvojem
sistema smo preizkušali omejitve obeh omenjenih žetonskih tehnik. Z namerno visoko
obremenitvijo in zgoščenostjo podatkov na samih izdanih dostopovnih žetonih smo
preizkušali kako se sistem obnaša v danih razmerah tako na strani odjemalca kot na strani
storitve. Rezultate testov smo nato statistično obdelali in tako prišli do zaključkov, ki
nakazujejo na nihanje in nepredvidljivo delovanje sistemov kadar žetonskih tehnik ne
uporabimo pravilno. Ugotovljeno je, da z implementacijo lastne obravnave žetonov
dvignemo samo kompleksnost izvorne kode rešitve saj sami skrbimo za izdajo in
obravnavo le teh. Analizirali smo vpliv komplekstnosti uporabljenih algoritmov za
zagotavljanje varnosti prenosa na samo odzivnost REST končnih točk. Tako smo višali,
nižali kompleksnost in tudi izklopili samo varnost, da bi ugotovili vpliv uporabe TLS na
samo performančnost končnih točk. Zaključili smo, da uporaba varnosti transpornega
nivoja - TLS doprinese do majhnih performančnih razlik vendar to ne odtehta, da bi za
namene performančne sposobnosti samo varnost na transportnem nivoju tudi izklopili.
vii
Comparison of JWT and OAuth 2.0 authorisation and
authentication techniques in REST services
Keywords: REST services, oAuth 2.0, JWT, token authentication, communication security,
authorisation, authentication
UDK: 004.056.523(043.2)
Abstract
The thesis addresses the area of using token authentication and authorisation for
software products that, for synchronization and communication purposes, take advantage
of underlying REST services. Given that REST service focuses on the use of HTTP protocols,
and that REST in its own principle requires being stateless, developers need to address
issues regarding user identification, authentication, and authorisation in a stateless
manner. In the thesis, we will also show the proper use of security protocols that are part
of the HTTP specification, and how to transmit and encrypt sensitive data properly
between two endpoints. We will do so by implementing a server and client and,
furthermore, present the communication flow needed for ensuring a strong security policy
that prevents system vulnerabilities and security flaws by implementing REST service that
is stateless and, for the purpose of user identification, uses two of the most common token
authentication implementations, OAuth 2.0 and JWT. Furthermore, we will compare the
basic principles and concepts of the two user identification frameworks and analyse the
benefits of both structurally and what to use in which given situation.
viii
Table of contents
1 INTRODUCTION .................................................................................................................... 1
1.1 Context .......................................................................................................................................... 1
1.2 Problem ......................................................................................................................................... 2
1.3 Approach and Research Questions ................................................................................................. 3
1.4 Objectives ...................................................................................................................................... 4
1.5 Structure ........................................................................................................................................ 5
1.6 Summary ........................................................................................................................................ 5
2 CONTEXT AND STATE-OF- THE-ART ............................................................................. 6
2.1 Context .......................................................................................................................................... 6
2.2 Problem ....................................................................................................................................... 10
2.2.1 Scalability and Stateless Communication ...................................................................................... 10
2.2.2 Security tokens and revocation problem ....................................................................................... 11
2.2.3 Client Token Lifecycle .................................................................................................................... 12
2.3 State-of-the-Art ............................................................................................................................ 12
2.3.1 Hardware Token Technologies ...................................................................................................... 12
2.3.2 Digital identity as user identificiation ............................................................................................ 14
2.3.3 Magnetic cards ............................................................................................................................... 14
2.3.4 RFID cards ...................................................................................................................................... 15
2.3.5 Biometric devices for automatic user authentication and authorization ...................................... 16
2.3.6 X.509 Certificates ........................................................................................................................... 17
2.3.7 Security Assertion Markup Language (SAML) ................................................................................ 18
2.3.8 Kerberos ticketing system .............................................................................................................. 18
2.3.9 User Authentication and Authorisation as a Service ..................................................................... 19
2.4 Summary ...................................................................................................................................... 21
3 ANALYSIS OF APPLICATIONS, FRAMEWORKS, PROTOCOLS AND
TECHNOLOGIES ......................................................................................................................... 22
3.1 Representational state transfer .................................................................................................... 22
3.1.1 Addressable resources ................................................................................................................... 22
3.1.2 Uniform and constrained interface ................................................................................................ 23
3.1.3 Representation-oriented ............................................................................................................... 24
3.1.4 Stateless communication ............................................................................................................... 24
3.1.5 Hypermedia As The Engine Of Application State ........................................................................... 24
3.1.6 Using HTTP status codes in REST architectural patterns ............................................................... 25
3.1.7 Using cache in REST services .......................................................................................................... 25
ix
3.1.8 Drawbacks of REST architectural pattern ...................................................................................... 28
3.2 Transport layer security ............................................................................................................... 28
3.2.1 Securing communication ............................................................................................................... 29
3.2.2 Identity and authentication ........................................................................................................... 29
3.2.3 Handshake protocol ....................................................................................................................... 30
3.2.4 Cipher suite negotiation................................................................................................................. 31
3.3 Javascript Web Token................................................................................................................... 31
3.3.1 JWT token structure ....................................................................................................................... 33
3.3.2 JWT Claims ..................................................................................................................................... 35
3.3.3 Standardization .............................................................................................................................. 38
3.3.4 Json Web Algorithms ..................................................................................................................... 42
3.3.5 Json Web Signature........................................................................................................................ 42
3.3.6 Authentication and communication flow ...................................................................................... 43
3.3.7 Critical vulnerabilities in JWT tokens ............................................................................................. 45
3.4 OAuth 2.0 ..................................................................................................................................... 46
3.4.1 OAuth 2.0 protocol roles ................................................................................................................ 46
3.4.2 OAuth 2.0 protocol flow ................................................................................................................ 47
3.4.3 OAuth 2.0 Authorisation grants ..................................................................................................... 48
3.4.4 Accesing protected resources ........................................................................................................ 50
3.4.5 OAuth 2.0 client registration.......................................................................................................... 51
3.4.6 OAuth 2.0 client types.................................................................................................................... 52
3.4.7 Client authentication ..................................................................................................................... 53
3.4.8 Other methods of authenticating clients ....................................................................................... 54
3.4.9 Serving unauthenticated clients .................................................................................................... 54
3.5 Session management, JWT and OAuth 2.0 comparison ................................................................ 54
3.5.1 Session management ..................................................................................................................... 54
3.5.2 JWT ................................................................................................................................................. 54
3.5.3 OAuth 2.0 ....................................................................................................................................... 55
3.6 Summary ...................................................................................................................................... 56
4 IMPLEMENTATION DETAILS, DESIGN AND TESTING ........................................... 57
4.1 Proposed solution ........................................................................................................................ 57
4.2 Functional requirements and application definition ..................................................................... 58
4.2.1 Application definition..................................................................................................................... 58
4.2.2 Functional requirements ................................................................................................................ 58
4.2.3 Technical requirements ................................................................................................................. 59
4.3 Market analysis of existing solutions ............................................................................................ 60
x
4.3.1 Functional comparison of applications .......................................................................................... 64
4.4 Architectural design ..................................................................................................................... 65
4.4.1 API Gateway pattern ...................................................................................................................... 65
4.5 General development tools .......................................................................................................... 67
4.6 Technologies and frameworks used ............................................................................................. 67
4.6.1 Apache Maven ............................................................................................................................... 67
4.6.2 Spring framework and Spring boot ................................................................................................ 68
4.6.3 Nginx .............................................................................................................................................. 69
4.6.4 Ensuring encrypted communication .............................................................................................. 69
4.6.5 Amazon web services ..................................................................................................................... 70
4.7 Application implementation details ............................................................................................. 71
4.7.1 Security configuration .................................................................................................................... 72
4.7.2 Client Domain and Server Subdomain Resolving ........................................................................... 73
4.7.3 Ensuring Secure communication ................................................................................................... 74
4.7.4 Obtaining Access and Refresh JWT token ...................................................................................... 75
4.7.5 Token Extraction and Token Validation Check ............................................................................... 76
4.7.6 Client Google drive integration ...................................................................................................... 78
4.8 Testing ......................................................................................................................................... 80
4.8.1 Testing Transport Layer Security ................................................................................................... 80
4.8.2 Load Testing on secure and unsecure channels............................................................................. 81
4.8.3 Testing the size impact of a token on performance ...................................................................... 83
4.8.4 Testing conclusions ........................................................................................................................ 87
4.9 Summary ...................................................................................................................................... 88
5 CONCLUSION AND FUTURE WORK ............................................................................. 89
5.1 Future work.................................................................................................................................. 91
5.2 Summary ...................................................................................................................................... 92
6 BIBLIOGRAPHY .................................................................................................................. 93
xi
List of figures
FIGURE 2.1 - INTEREST OVER TIME REST VS. SOAP ..................................................................................................... 8
FIGURE 2.2 - SEARCH TERM INSIGHTS "REST", "SOAP", "CLOUD COMPUTING" .............................................................. 9
FIGURE 2.3 - PROBLEM REPRESENTATION ................................................................................................................. 10
FIGURE 3.1 - GRAPHIC REPRESENTATION OF HANDSHAKE PROTOCOL ............................................................................. 31
FIGURE 3.2 - JWT TYPE DEFINITION ......................................................................................................................... 33
FIGURE 3.3 - JWT HEADER ................................................................................................................................... 34
FIGURE 3.4 – JWT PAYLOAD EXAMPLE .................................................................................................................... 34
FIGURE 3.5 - JWT SIGNATURE EXAMPLE ................................................................................................................... 35
FIGURE 3.6 - JWT COMPACT STRUCTURE ................................................................................................................. 35
FIGURE 3.7 - RESERVED CLAIMS EXAMPLE ................................................................................................................. 38
FIGURE 3.8 - JWK EXAMPLE .................................................................................................................................. 40
FIGURE 3.9 - JWS JSON SERIALIZATION .................................................................................................................. 43
FIGURE 3.10 - JWT AUTHORISATION HEADER PARAMETER ........................................................................................... 44
FIGURE 3.11 - JWT AUTHENTICATION AND COMMUNICATION FLOW ............................................................................. 44
FIGURE 3.12 - OAUTH 2.0 ROLES ........................................................................................................................... 47
FIGURE 3.13 - OAUTH 2.0 PROTOCOL FLOW ............................................................................................................ 48
FIGURE 3.14 - AUTHORISATION CODE GRANT PROTOCOL FLOW ..................................................................................... 49
FIGURE 3.15 - USING REFRESH TOKEN FLOW ............................................................................................................. 51
FIGURE 3.16 - GOOGLE API CONSOLE ...................................................................................................................... 52
FIGURE 4.1 - USE CASE DIAGRAM ............................................................................................................................ 59
FIGURE 4.2 - ORPHEUS ANDROID APPLICATION ......................................................................................................... 61
FIGURE 4.3 - MUSIC SHEET ANDROID APPLICATION .................................................................................................... 62
FIGURE 4.4 - MUSE SCORE ANDROID APPLICATION .................................................................................................... 63
FIGURE 4.5 - SONGBOOK MOBILE APPLICATION .......................................................................................................... 63
FIGURE 4.6 - API GATEWAY PATTERN ..................................................................................................................... 65
FIGURE 4.7 - GLOBAL ARCHITECTURAL DESIGN ........................................................................................................... 66
FIGURE 4.8 - MAVEN PROJECT OBJECT MODEL (POM) EXAMPLE ................................................................................. 68
FIGURE 4.9 - THREE TIER ARCHITECTURE WITH INTERCEPTOR ........................................................................................ 72
FIGURE 4.10 - DNS ADDRESS RESOLVING ................................................................................................................. 74
FIGURE 4.11 - REQUEST RETRANSMISSION ................................................................................................................ 74
FIGURE 4.12 - OBTAINING ACCESS AND REFRESH TOKEN .............................................................................................. 75
FIGURE 4.13 - TOKEN VALIDATION .......................................................................................................................... 76
FIGURE 4.14 - SONG ADDITION DIALOGUE ................................................................................................................ 78
FIGURE 4.15 - GOOGLE DRIVE INTEGRATION ............................................................................................................. 79
FIGURE 4.16 - SONG ADDITION AND PLAYING ............................................................................................................ 79
xii
FIGURE 4.17 - TLS/SSL TESTING SCORE ................................................................................................................... 81
FIGURE 4.18 - LINE GRAPH OF TOKEN IMPACT ON PERFORMANCE .................................................................................. 87
xiii
List of tables
TABLE 3.1 - MOST COMMONLY USED HTTP METHODS AND THEIR USAGE BASED ON CRUD ............................................... 23
TABLE 3.2 - HTTP STATUS CODES AND USAGE IN REST ............................................................................................... 25
TABLE 3.3 - CACHING HEADER PARAMETERS .............................................................................................................. 26
TABLE 4.1 - COMPARISON OF MUSIC APPLICATIONS .................................................................................................... 64
TABLE 4.2 - SCORING TABLE OF SSL/TLS TESTING TOOL SSL LABS ............................................................................... 80
TABLE 4.3 - TEST RESULT UNSECURE CHANNEL ........................................................................................................... 81
TABLE 4.4 - STATISTICAL OVERVIEW OF TESTING UNSECURE CHANNEL ............................................................................. 82
TABLE 4.5 - TESTING RESULTS ON SECURE CHANNEL .................................................................................................... 82
TABLE 4.6 - STATISTICAL OVERVIEW OF SECURE CHANNEL RESULTS ................................................................................. 83
TABLE 4.7 - TESTING RESULTS` COMPARISON ............................................................................................................. 83
TABLE 4.8 - TESTING SIZE IMPACT FIRST ITERATION ..................................................................................................... 84
TABLE 4.9 - TESTING SIZE IMPACT SECOND ITERATION.................................................................................................. 84
TABLE 4.10 - TESTING SIZE IMPACT THIRD ITERATION .................................................................................................. 84
TABLE 4.11 - TESTING SIZE IMPACT FOURTH ITERATION ............................................................................................... 85
TABLE 4.12 - TESTING SIZE IMPACT FIFTH ITERATION ................................................................................................... 85
TABLE 4.13 - TESTING SIZE IMPACT SIXTH ITERATION ................................................................................................... 85
TABLE 4.14 - TOKEN SIZE IMPACT ON PERFORMANCE .................................................................................................. 86
xiv
List of source code
SOURCE CODE 1 – SECURITY POLICY CONFIGURATION .................................................................................................. 73
SOURCE CODE 2 - INTERCEPTOR REGISTRY CONFIGURATION .......................................................................................... 73
SOURCE CODE 3 - AUTHENTICATION FILTER ............................................................................................................... 77
SOURCE CODE 4 - JWT MANAGER TOKEN VALIDATION ................................................................................................ 78
xv
List of Acronyms
AES Amazon Elasticsearch Service
API Application Programming Interface
AWS Amazon Web Services
B2B Business-to-Business
CA Cerificate Authority
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit
CRUD Create, Read, Update and Delete
DCOM Distributed Component Object Model
DP Density-independent Pixels
ECDSA Elliptic Curve Digital Signature Algorithm
HMAC Hash-based Message Authentication Code
HTML Hyper Text Media Language
HTTP Hypertext Transfer Protocol
HTTPS Secured Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IM Instant Messaging
IOC Inversion Of control
IOS Iphone Operating System
IoT Internet of Things
IP Internet Protocol
JAR Java Archive
JavaEE Java Enterprise Edition
JPA Java Persistance API
JSON JavaScript Object Notation
JWA Json Web Algorithms
JWE Json Web Encryption
JWK Json Web Key
xvi
JWS Json Web Signature
JWT JavaScript Web Token
MIDI Musical Instrument Digital Interface
MITM Man In The Middle
RAM Random Access Memory
REST Representation state transfer
RFID Radio Frequency IDentification
RFC Request For Comment
RSA Rivest, Shamir, Adleman cryptosystem
RSA Random Secure Authentication
RSA-PSS RSA Probabilistic Signature Scheme
SAML Security Assertion Markup Language
SD Secure Digital
SES Simple Email Service
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple object transfer protocols
SSL Secure Sockets Layer
TLS Transport Layer Security
URI Uniform Resource Identifier
VoIP Voice Over Internet Protocol
WS Web Service
XML Extensible Markup Language
YAML YAML Ain't Markup Language
xvii
1
1 INTRODUCTION
In the introduction to this dissertation, there is a brief explanation of the contextual
representation of the problem at hand, and perspective and concepts that derive from
the given context. The problem that is to be solved is also addressed, together with the
research questions that will be used, approaches to the research questions and goals that
are to be achieved in the context of this dissertation.
1.1 Context
Throughout history, we have seen the evolution of internet pages that offered only basic
information, to web pages being defined as a bigger business service to a given user. A
bigger business service means that web pages can be exposed as an application that
provides additional value to the client by processing inputs and providing calculated
enriched output. For an application to be reachable by users remotely, it has to be hosted
on a certain computer, called a server. The main purpose of a server is to process
requests and serve resources and files to its clients.
The client requests the content and sends the additional information to the server. The
server processes the client`s request with data and responds with the result. This model
of communication is defined as the client-server model. When the only clients were
browsers, the server returned the result as a Hyper Text Markup Language (HTML) page,
but, since applications nowadays have to support multiple possible clients, developers
needed to think of new ways to serve the results to their clients.
In order to serve results to multiple technology-independent clients like mobile
applications, Internet of Things (IoT) devices, native desktop applications, the developers
transformed the applications that serve responses as HTML pages which are meant to be
presentable to humans into serving responses that are more readable by computers.
Developers achieved more readable computer formats by exposing their applications as
web services and Application Programming Interfaces (API), which enabled structured
communication from computer to computer.
2
For API development, developers have used mostly an architectural pattern called
Representational State Transfer (REST), in order to create a gateway which is capable of
serving data to technology independent clients. A REST architectural pattern, by its
definition, states that an application should not save any application state on a server by
any means and, given the consideration of this policy, users` sessions cannot be stored.
This principle enables the client and the server not to be tightly coupled, and that a client
can be independent of the technologies used. In that way, a client can be a native
desktop application, mobile device, browser, or any other kind of application. Since
applications can no longer save users` sessions, an alternative for providing user identity
has been introduced, called tokens. Tokens are small, compact, encoded and signed
representations of a user’s identity that provide access to the server resources and prove
users` identities. The general concept relies on exchanging user credentials for a token
that is valid for a certain time period.
Today there are two commonly used de facto technologies for user authentication and
authorisation, called Javascript Web Tokens (JWT) and OAuth 2.0. Both implementations
are part of open source standardization, and have a valid entry in Request For Comment
(RFC) on Internet Engineering Task Force (IETF).
1.2 Problem
As said, users can, nowadays, use many different client technologies in order to access
application endpoint, different client technologies, such as mobile devices and mobile
applications, web browsers, and native desktop applications. Session and cookie
management becomes unbearable in terms of server resources and performance.
Another possible drawback is also the security concerns involving cookie handling.
Cookies are, technically speaking, only text files that are stored by the client's browser
and contain information. If they are sent with a request over an unsecured channel
possible attackers could intercept the request and extract the session information.
This information can then be used to impose as a valid user of the system. This technique
is called session hijacking, and is a really common attack used by malicious software and
attacker to compromise system security. Given all the performance and security
3
drawbacks, there was a necessity to create a concept that would introduce a light, robust,
small enough and self-contained storage, that could be given to a client as a session
alternative. It also has to impose and provide the security encryption, decryption and
signing of vulnerable data, since the data is stored on the client side.
Tokens are small encoded representations of a user valid session. They are small enough
to be transferred with every subsequent request and, like cookies and sessions, they are
only valid for a certain amount of time. Scalability can be done easily, since tokens are
stateless and require no shared session management between particular instances of
servers` side API. There are some drawbacks when using tokens, which will be addressed
in the following sections.
1.3 Approach and Research Questions
It is important to define the most common drawbacks that are issued when using session
management, and how developers can benefit from the stateless implementation of REST
architectural pattern with the usage of token identification. To do so, we will implement a
prototype android application that helps musicians manage and organise sheet music.
The application will be implemented on the client side, as well as on the server side. This
way, token lifecycle management can be analysed on the client side and, on the server
side, token issuing, revocation and validity checking.
The importance of the communication flow security will also be analysed between REST
API and the client. Underlying security protocols, such as Transport Layer Security (TLS)
and Secure Sockets Layer (SSL), which enable encrypted communication, will be
presented theoretically. Furthermore, the correct usage of storing sensitive data into the
token itself will be shown, and the usage of symmetric and asymmetric cryptography to
encrypt sensitive data.
Further research on how the size of the token affects the performance of communication
and what can be done to optimise the given communication flow.
4
Main question: Does the implementation of a solution that follows fundamental
principles of stateless communication in REST and addresses user authentication and
authorisation using security token implementation JWT and OAuth 2.0 provide a
higher level of scalability and security?
Because the main question includes a broad spectrum, Sub Questions have been defined
which will help provide a more detailed and structured approach in answering the main
question.
Sub Questions (“SQ”) are as follows:
SQ 1 How does implementing and usage of TLS/SSL impact the
performance of the REST endpoint?
SQ 2 How does the implementation of token security and size of the
token impact the performance of the communication flow?
SQ 3 Does implementing custom JWT token security authentication or
implementation of OAuth 2.0 cause higher complexity of code?
SQ 4 Does the usage of Secured Hypertext Transfer protocol (HTTPS)
ensure secure transfer of token from client to server?
During this dissertation, answers to these Sub Questions will be provided. Furthermore,
explanations will be given on the overall impact of these Sub Questions on the main
research question.
1.4 Objectives
The author wants to address the scalability and compatibility issues related to when
developers and companies do not implement stateless services and tend to use session
management control for user authentication and authorisation. Furthermore,
understanding the structure of an issued token, communication flow, roles that are given
in accessing the data and overall security pitfalls that need to be considered when
implementing token authentication and authorisation is addressed. By implementing
both server and client sides, issues will be presented that are most common for both
parties of heterogeneous systems.
5
1.5 Structure
Chapter 2, Context & State-of-theart, provides information about the
contextualization and thorough problem definition. Furthermore, during this
chapter, the state-of-the-art from a hardware and software perspective is
addressed, in order to present correlated factors involving token authorisation
and authentication.
Chapter 3, Analysis of applications, frameworks, protocols and technologies
focuses on detailed analysis of applications and protocols that enable the usage of
token authorisation and authentication.
Chapter 4, Implementation details, design and testing, presents implementation
details, architectural designs and diagrams that were used as a part of the project.
This chapter also provides details about token testing and their impact on overall
performance.
Chapter 5, Conclusion and future work, concludes the dissertation with the
provided limitations, future work remarks, and final conclusions.
1.6 Summary
During this chapter, Research Questions and Sub-Questions have been defined that are
needed for systematic addressing of the problem at hand. To address the issue further a
brief context, document structure and perspective have been provided. Lastly, the
conclusion of the chapter with the objectives and goals needed.
6
2 CONTEXT AND STATE-OF-THE-ART
Thorough and structured description details and contextualization of the problem are
discussed n this chapter. Furthemore, the definition of the state-of-the-art is analysed
from the hardware and software perspectives.
2.1 Context
Since the development of the Internet, developers have tried to communicate between
heterogeneous systems in order to support distribution and real time updating. We have
seen the evolution of sending an unstructured stream of bytes to sending structured data
formats across the network as an exchange protocol that defines communication
between two systems. In order to offer more stable, robust structured data transfer, web
services were derived as an evolution from sending binary data streams, and, thus,
replacing technologies such as Common Object Request Broker Architecture (CORBA) and
Microsoft’s Distributed COM (DCOM). Structured data formats were needed in order to
exchange information based on computer readable requests which use the extent of
markup language, such as Extensible Markup Language (XML). It was the beginning of the
era that brought a big shift in the general architectural principles and communication
patterns called Service Oriented Architecture (SOA). According to David Sprott and
Lawrence Wilkes, SOA architecture can be defined as:
»The policies, practices, frameworks that enable application functionality to be
provided and consumed as sets of services published at a granularity relevant to the
service consumer. Services can be invoked, published and discovered, and are
abstracted away from the implementation using a single, standards-based form of
interface.« [1].
SOA architecture was an evolution in development because of the need for breaking
down large information systems, which were hard to maintain, into smaller, modular and
reusable fractions. In order to achive modularity and reusability, web applications were
formed into smaller fractions, called Web Services (WS), that enabled interaction using
the HTTP protocol and unique Uniform Resource Identifier (URI) endpoint definition. Web
7
service itself still had to provide their definition of usage and a set of supported
operations, their input and output. The World Wide Web Consortium (W3C) defined Web
Service as:
»A software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a format that machines
can process (specifically WSDL). Other systems interact with the Web Service in a
manner prescribed by its description using SOAP messages, typically conveyed using
HTTP with XML serialization in conjunction with other Web-related standards« [5].
Simple Object Access Protocol (SOAP) was designed by Microsoft in 1998 by Dave Winer,
Don Box, Bob Atkinson and Mohsen Al-Ghosein [6], and SOAP Web services were quickly
adopted by Business To Business (B2B) systems as a part of communication message
interchangeable protocol, which offered a structured definition of web service endpoint
and correlated input and output.
Everlasting changes during the development process bring a lot of problems when using
SOAP protocol, because it is not easily modifiable, since the developer has to change the
service implementation, service definition and change the endpoint request and response
optionally. In order to develop the technology that uses HTTP protocol as a definition of
architectural style, provides higher scalability options and is quicker to adopt and change,
in the year 2000, Roy Fielding presented in his PhD [9] an architectural pattern called
REST, that uses underlying HTTP protocol as a part of wWeb Service definition.
The REST architectural pattern was quickly adopted as an alternative for SOAP service
endpoints. The major deviation between REST and SOAP is that REST relies strongly on
HTTP protocols and underlying concepts, and is defined as an architectural pattern. SOAP,
on the other hand, is defined as a protocol, and it is not necessary for SOAP to use HTTP
as a protocol for message interchange. By using SOAP, it is also possible to send messages
using the Simple Mail Transfer Protocol (SMTP) protocol. Because SOAP is defined as a
protocol, it offers a stricter and structured approach, and there are many sub-standards
that extend the use of the SOAP protocol. These include WS-Security, WS-Reliable
Messaging, WS-Atomic Transaction, and more. These sub-standards define how to handle
8
security and message exchange based on a protocol. [11] REST, on other hand, is not
defined as a Standard and has to rely on sub protocols of HTTP such as TLS / SSL which
address security and message handling.
Even though the SOAP protocol is still in use today, many believe that interchanging the
information using the structured mark-up language called XML brings too much overhead
to the request and response of web service endpoints. The size of the request and
response affects the performance of a Web Service endpoint directly, because of
additional processing of the request. That is one of the reasons that REST surpassed the
use of SOAP. Some evidence of this can be found by looking at the Google Trend index.
In both figures (Figure 2.1, Figure 2.2) the Y – AXIS represents the popularity index
calculated by Google in which 100 represents the highest peak of popularity and 0
represents the lowest peak of popularity. The X-AXIS of the chart represents the timeline
from the year 2004 to the present day. Regionally speaking, we do not have limitation
regarding a specific region or country, but rather addressed to the popularity index
worldwide.
Figure 2.1 - Interest over time REST vs. SOAP [10]
In Figure 2.1 the blue line represents the REST architectural pattern, and the SOAP
protocol is the red line. In July 2011, the search for REST had finally surpassed the SOAP
protocol.
The situation becomes clearer if an additional search term is defined as “Cloud
computing”, as seen in Figure 2.2
9
Figure 2.2 - Search term insights "REST", "SOAP", "Cloud Computing" [10]
It has become somewhat clearer that the rise of cloud computing proposed the need for
Web Service technology that is more adaptable, scalable and, most importantly, stateless
by definition.
Given the evolution of Web Services and API, major differences between the REST
architectural pattern and SOAP protocol can be defined as follows:
1. REST is gaining leverage by most tools that are open for external communication
since, by definition, REST API is decoupled from the client, which means that the
service can be changed easily;
2. SOAP Services are harder to scale;
3. Comparing the learning curve required for both technologies, REST offers quicker
adoption and implementation. This means that companies can save money and
time when adopting a REST architectural pattern;
4. REST uses primarily smaller message exchange format. When using SOAP, XML
format has to be used for interchanging the information, which brings
unnecessary overhead in the message. Smaller messages mean quicker response
time and better performance when using cache technologies on top of service
interfaces;
5. REST relies primarily on underlying HTTP Standards, thus making it more diverse
when taking into consideration communication over the web.
REST architectural style and HTTP is, by definition, stateless, meaning that every
subsequent request has no correlation with any previous request made. This also means
10
that, at any given time, the server must not store any application state, as seen in the
examples of session storage and session management. The lack of application state
causes that the user authentication and authorisation problems have to be addressed
differently.
2.2 Problem
Due to clients accessing services using different, technology independent clients, such as
tablets, phones and native desktop applications, companies had to figure out a way to
serve information as one unified resource accessible from the web. Serving multiple
clients was only possible if existing web applications had an extra layer of integration
abstraction using web services, or if the web application was decoupled al- together and
exposed as an independent Web Service.
Figure 2.3 - Problem representation
2.2.1 Scalability and Stateless Communication
“Scalability is the capability of a system, network, or process to handle a growing
amount of work, or its potential to be enlarged to accommodate that growth.”
(Bondi, 2000).
When scalability in Web Services is discussed, two main different versions of scaling must
be taken into account – vertical and horizontal. Vertical scaling provides growth by adding
resources to the single server. These resources could either be a Central Processing Unit
11
(CPU), Random Access Memory (RAM) or storage. This type of scaling usually requires
downtime and restarting because of the addition of physical units to a single server.
Horizontal scalability, however, is achieved by adding additional replicated servers that
are able to process the growing number of requests. Servers, when added, register to a
load balancer which serves as a distributor of the requests, and together server and load
balancer present as a single logical unit.
If the capability of resource expansion and the prevention of downtime are to be
achieved, design and implementation need to be completely stateless. Shared session
management is possible when using horizontal scalability, but uses a lot of memory
resources. In order to achieve the minimum memory footprint, everything needed for
authorisation and authentication has to be handed over to the client.
2.2.2 Security tokens and revocation problem
Assuming that a REST API has been implemented completely stateless with the usage of
user authentication and authorisation strategy (JWT, OAuth 2.0) means that every token
is valid for a certain amount of time. After that time has expired the token becomes
invalid. The problem is when a token is issued that is valid for a certain amount of time,
but the administrator wants to invalidate access to a certain user and their issued token
before the token expires. In order to do so, developers need to provide some kind of
implementation of the revocation list that is checked every time user wants to access
restricted URI. If there are a lot of revocations, developers are facing the same problems
that they had when using session management, such as high memory usage.
As API is developed, the token that is sent from server to client needs to be sent using
secured channels that ensure secure token transmission. Because REST uses underlying
HTTP protocols for message exchange, securing a channel is achieved by using the
protocol that secures HTTP, such as TLS/SSL. Achieving strong and secure security
transmission can affect the performance of API and client communication, because an
additional computational cost is required when establishing a secure channel.
12
2.2.3 Client Token Lifecycle
The client that receives a token must follow a concrete and robust life cycle of token
management, token storing, invalidation and reissuing. If the client is not storing tokens
correctly, such as in memory, they can pose security vulnerabilities. There are a lot of
concepts, technologies, and principles that need to be considered when implementing a
solution that is capable of scaling and is using stateless REST fundamental principles. It is
really important that developers think of this problem in the early stages of development
and architectural design. If developers do not acknowledge these principles early, the
company could issue a serious outage on service, meaning that they will lose revenue.
2.3 State-of-the-Art
This section provides in depth analysis of existing technologies and hardware that include
the topic that has been addressed in this dissertation.
2.3.1 Hardware Token Technologies
Hardware token authentication is used mostly in the implementation of two-factor
authentication. Hardware token authentication is used primarily by banks and
governments, where a high level of security is a top priority. In this subsection, the two
most popular hardware token technologies will be described, Random Security Access
securID (RSA SecurID) [14] and YUBIKEY [15].
2.3.1.1 RSA SecurID
RSA SecurID is a hardware token, presented in Figure 2.3 - RSA SecureID Hardware token
[14], developed by a company called The Security Divison of EMC. The RSA SecurID token
is responsible for generating time limited tokens which are represented by six numbers
and are required for the use of two-factor authentication. A hardware token uses the
capabilities of a built-in clock mechanism and factory-encoded random key which is
known as a »seed«. For the purpose of providing the higher level of security, the seed is
different for every token generated. RSA SecurID has been designed to be tamper-
resistant in order to make a device resilient to reverse engineering [14].
13
Figure 2.3 - RSA SecureID Hardware token [14]
The purpose of RSA SecurID hardware tokens is to provide an additional security layer of
the web resource. In a practical way, a user would have to provide their authentication
details, such as username and password, alongside the token generated on an RSA
SecurID hardware token.
2.3.1.2 YUBIKEY
YubiKey, as seen in Figure 2.4, is a market competitor to RSA SecurID in the hardware
token device market segment. A YubiKey hardware token is a device developed by a
company called Yubico. Currently, YubiKey supports the generation of one-time
passwords, public key encryption, and user authentication, through the support of the
Universal 2nd Factor (U2F) protocol. The U2F protocol was defined by the Fast Identity
Online Alliance (FIDO) which was formed as an industry consortium. The founders of the
FIDO Alliance were the companies Nok Nok Labs, Paypal and Lenovo, and today the
consortium consists of companies such as Synaptics, Google, MasterCard, Microsoft, Bank
of America, and more. Yubikey uses an algorithm called HOTP, the implementation of the
Hash-based Message Authentication Code (HMAC) algorithm based one-time password
algorithm. YubiKey focuses primarily on allowing users to sign, encrypt and decrypt
messages with the use of a private key which is stored on the key itself, thus enabling safe
storage on a physical device without exposing the key to the public [15].
14
Figure 2.4 - YubiKey hardware token [15]
YubiKey was adopted by many companies and platforms, such as BitBucket, Dropbox,
Facebook, GitLab, GitHub and Microsoft [15].
2.3.2 Digital identity as user identificiation
Digital identity provides user authentication and authorisation by questioning the user
on:
1. What do you know?
2. What do you have?
In terms of digital identity, users can provide a username and associated passwords when
providing digital identity. These credentials provide an answer to the question on what do
you know. Another technique on digital identity is by providing a valid digital certificate
with corresponding public key that enables a certain entity to verify user legitimacy.
Digital certificates are issued by trusted Certificate Authorities (CA) which ensures the
validity of a digital certificate provider [69].
2.3.3 Magnetic cards
Plastic identification cards with technologies for information storage have been around
for quite some time now. Magnetic cards were introduced by a company called IBM with
the introduction of the first prototype. The first prototype was introduced in 1970 by a
Company Engineer, Forrest Parry [70]. This has been groundwork for many improved
versions of identification cards.
A magnetic card, as seen in Figure 2.5, is a plastic identification card that holds the
information using a magnetic strip. The data on the magnetic strip is stored by modifying
15
the magnetism of magnetic particles on the strip. The information on the magnetic cards
is stored on three magnetic tracks that hold the information. The data on the card can be
read by swiping the card against a magnetic card reader. A magnetic strip can hold
information about the user or a certain entity [70]. The most popular usage of magnetic
cards is in the financial sector, such as credit cards, debit cards.
Figure 2.5 - Magnetic card [73]
2.3.4 RFID cards
Radio Frequency IDentification (RFID) cards offer a contactless authentication and
authorisation of a person. RFID cards, as seen in Figure 2.6, are plastic ID cards with an
incorporated chip that holds personal information. Compared to magnetic cards, RFID
cards must only be in close proximity to an authorisation device in order to exchange
information. RFID cards contain a transponder that is activated when a transceiver sends
a radio frequency activation signal. The transponder reacts to the activation signal and
sends identification details. A transceiver decodes the information and passes the data to
the computer, which uses data for further processing [71]. The use of RFID technology
can be seen in areas, such as:
1. Access and restriction;
2. Tracking
a. Tracking of product;
b. Tracking of animals;
3. Contactless payment;
4. Travel documents;
5. Time measurement in sports;
16
6. Billing processes;
7. Public transportation.
Figure 2.6 - RFID card and reader [74]
2.3.5 Biometric devices for automatic user authentication and authorisation
Biometric devices are devices for automatic user authentication based on verification of
physiological or behavioural human characteristics, such as:
1. Fingerprints;
2. Facial images;
3. Voice recognition;
4. Eye characteristics` recognition (also called Iris prints);
Biometric devices, as seen in Figure 2.7, automate and enhance the reliability of the user
authentication and authorisation process. This is achieved in such a way that a biometric
device is capable of full recognition of a person based on one, or a combination of, user
unique biological characteristics.
The usage of biometric devices in user authentication is primarily for workplace and home
areas, where a restriction of access to a specific area based on unique biological patterns
is required [72]. The use of biometric devices can also be found in personal identification
areas, including
1. Immigration;
2. Mobile phones, tablets, laptops and smart devices;
17
Figure 2.7 - Fingerprint scanning [75]
2.3.6 X.509 Certificates
In asymetric cryptography there is a mathematical relation between public and private
keys. Content that is encrypted by a public key can be decrypted by using a private key.
X.509 is Standard that specifies the format and formal specification of public key
certificates in asymetric cryptography. Public key certificates can be used to verify that a
certian public key belongs to a user, computer, service or organisation – identity
verification. X.509 certificates are signed by a Certificate Authority (CA), which
guarantees the verification and validity of the party that holds the certificate.
The most common usage of X.509 public key certificates is in TLS/SSL, for ensuring the
encrypted traffic and verfiying the communication parties.
X.509 certificates can be used in Web Services as a concept that identifies and validates
the client trying to connect. With every subsequent request the client sends along, the
certificate that proves his authenticy or, depending on the service protocol,identity
verification can be agreed before session initialization.
18
2.3.7 Security Assertion Markup Language (SAML)
SAML is an open subset of Standards that define exchanging authentication and
authorisation details between two parties – identity provider and service provider. SAML
is an XML structured definition for security assertions. The main advantage of SAML
proved to be in a single sign in technique across multiple domains. SAML provides the
definition of three main roles.
1. The principal (user/clients)
2. IDentity Provider (IDP)
3. Service Provider (SP)
IDentity Provider (IDP) is the SAML role specified for identity control authentication and
authorisation. Additional information about some user can also be obtained from an ID
Provider.
Service Provider – The SAML role responsible for form or an SSO application provider.
2.3.8 Kerberos ticketing system
Kerberos is a native authentication protocol that is used for proving identity verification
for communication in non-encrypted internal or external networks. Kerberos uses a
concept called tickets. In the Kerberos system, the user uses his credentials to encrypt the
content. The Key Domain Controller (KDC) is aware of the user`s credentials and uses
them to decrypt the content. If the symmetric encryption and decryption are valid, the
Kerberos system issues a security token. With the security token, a client can request
from KDC a security ticket to access a certain web server or a web service. In this way, a
higher layer of security abstraction is implemented. [76] Even if your credentials are
correct, you can only access the certain services and server that are in your domain. This
is called the Kerberos Realm. Users, Servers and services are placed in the Kerberos realm
of the KDC that controls the access.
19
Figure 2.8 - Kerberos workflow [76]
As seen in Figure 2.8, »Alice« represents the client trying to connect to the service. The
terms AS stands for »Authentication Service« and the term TGS stands for »Ticket
Granting System«. The client uses his credentials in order to obtain a Kerberos ticket. The
client can now proceed to access Service using the Kerberos ticket.
2.3.9 User Authentication and Authorisation as a Service
Since user registration information has become a major security risk, many companies
started to offer user authentication and authorisation as a service. User registration as a
service means that the user information management, token issuing and revoking, login
and registration, is delegated to a third-party provider. The application then uses a special
integration layer with third-party providers that enable token verification and token
management. A key motivation for using such a service would be enabling users a single-
sign-on, throughout different platforms and solutions that a certain company provides.
2.3.9.1 Amazon Cognito
Amazon Cognito is a user identity management platform, developed by a company called
Amazon, which offers easier user registration and user login for mobile device
integration. Amazon Cognito also offers options for the user to use social sign in as well as
the web user management application. The principle of usage can be seen Figure 2.9.
Another special aspect is that it enables easy cross device data synchronization [20].
20
Figure 2.9 - Amazon Cognito [20]
The pricing of the Amazon Cognito is based on Monthly Active Users (MAU). For Amazon
an MAU is considered as:
»if within a calendar month, there is an identity operation related to that user, such as
sign-up, sign-in, token refresh or password change« [20].
2.3.9.2 Okta
Okta is an alternative to Amazon Cognito that offers user management and user
authentication and authorisation as a service. Its primary features include:
1. User Registration to Okta;
2. Password Management;
3. Authentication;
4. User Profile;
5. User grouping;
6. Session and Policy Management.
The main difference between Okta and Amazon Cognito is that Okta offers multi-factor
authentication for users using two other factor security services like RSA SecurID, Duo
Security, Google Authentication, Symantec VIP. Customers can also use verification using
a mobile verification code sent via the Short Message Service [21].
21
2.4 Summary
During this chapter, the problems have been discussed from the technical and social
aspects, Together with the definition of the technical problems a developer is facing
when trying to develop a stateless web service in order to achieve as much scalability and
elasticity as possible. Furthermore, the problems have also been presented that derive
from developing such applications. The definition of state-of-the-art from the perspective
of software and hardware has been outlined in a way that has been identified in the
already developed solutions on the market and how the proposed solution deviates.
22
3 ANALYSIS OF APPLICATIONS, FRAMEWORKS, PROTOCOLS AND TECHNOLOGIES
In this chapter, we will provide details of the protocols, frameworks, and technologies
that are needed to create the stateless, elastic and scalable solutions. We will address
technical aspects and concepts of the two most used Standards for token user
authentication and authorisation. Furthermore, we will explain thoroughly in detail all the
correlating factors that influence the architectural design in implementing a secure,
scalable solution.
3.1 Representational state transfer
Also known by its abbreviation REST, it is an architectural pattern that defines basic
principles and concepts used for interoperability of heterogeneous software systems
using underlying Standards and protocols defined by the web specification [63]. Web
Services that are implemented using REST principles enable textual representation of web
resources with the usage of defined operations that, in their essence, do not save any
state. Compared to other technologies used, such as SOAP, REST is not defined as a
protocol, but as a concept or, in the terms of software development, as an architectural
pattern. Because it is not defined as a protocol, REST cannot be defined as a Standard.
Main architectural pattern concepts:
1. Addressable resources;
2. Uniform and constrained interface;
3. Representation-oriented;
4. Stateless communication;
5. Hypermedia As The Engine Of Application State (HATEOS).
3.1.1 Addressable resources
Access to any resource of application is enabled by using unique identifiers, known as
URI. When we are talking about a resource, we are basically meaning the key abstraction
of information and data. URI is used most commonly in a client such as browsers [63].
The server serves as the distributor of information by using the underlying HTTP protocol.
23
3.1.2 Uniform and constrained interface
All the interactions between client and server have to be defined as a limited set of
predefined HTTP methods and/or operations. The client does not have to rely only on the
HTTP GET method and URI parameters for interaction, but can use multiple different
defined HTTP methods as a part of communication between two parties [63].
The Idempotent/safe methods of HTTP mean that we can call a specific operation of the
resource and the result will always be the same. This means a specific operation does not
change the state of resource on a server. In Table 3.1 we describe four HTTP methods
that can be related to the model of Create, Read, Update and Delete (CRUD) of the
resource.
Table 3.1 - Most commonly used HTTP methods and their usage based on CRUD
CRUD Operation HTTP Method Definition Safe method Idempotent
method
Create resource POST Defined as an
operation for
creating a new
resource
NO NO
Read resource GET Getting the
information of
the current state
of the resource
YES YES
Update resource PUT Updating the
information of a
given resource
NO YES
Resource
deletion
DELETE Deleting or soft
deleting the
given resource
NO YES
24
3.1.3 Representation-oriented
Every particular web resource can be represented using numerous different formats,
given that different clients prefer different textual and/or binary representation of data
[63]. The most used data representation formats when using REST service are as follows:
1. XML;
2. JSON;
3. (X)HTML;
4. YAML;
5. Plain text.
When we are implementing a web resource, we can also consider the option that the
client itself tells the format in which he wants the data to be represented.
3.1.4 Stateless communication
Every subsequent request that is sent to the server has to be self-sufficient, meaning it
should not be dependent on any previous requests. We can achieve statelessness
through a number of different techniques and mechanisms:
1. By implementing methods and communication through a system that does not
require any state saving;
2. Transitioning the server state without preserving the application state;
3. Passing the state back to the client, if necessary, by the end of each request.
3.1.5 Hypermedia As The Engine Of Application State
Also known by its abbreviation, HATEOAS is an important constraint of the REST
architectural pattern. It differentiates from other network application architecture by the
principle that a client interacts with server-side API entirely, using hypermedia provided
dynamically by the application server [63]. A client that is using REST API does not need
any prior knowledge how to interact with any particular application. In that way, the
client and server are decoupled, and allow for the server to evolve and change
independently from the client itself. HATEOAS constraint has been defined as the
essential part of the uniform interface feature of REST architectural pattern as defined in
Roy Fielding’s Ph.D. dissertation.
25
3.1.6 Using HTTP status codes in REST architectural patterns
The REST architectural pattern focuses on the underlying HTTP status code when serving
responses. It is still not standardised what HTTP status codes to use in which cases, but it
is a sort of a de facto agreement what to use in certain cases. The Standard itself does not
impose what to use in certain cases, meaning it is application specific. In Table 3.2 we
present the most commonly used status codes and their meanings.
Table 3.2 - HTTP status codes and usage in REST
Status code Description
200 OK Status code for a response that has been served
successfully. We would normally use this status code for the
GET, POST, PUT, and DELETE HTTP methods
201 Created The resource was created successfully
400 Bad Request The given request was not addressed properly
401 Unauthorised This status code could be used as serving when a user has
provided the wrong credentials
403 Forbidden This status code is used when a user is trying to reach a
resource but hasn’t got any of the required roles to
complete the request successfully
404 Not found The request resource was not found
405 Method not allowed This status code means that the client was using an HTTP
method that is not supported on the server.
500 Internal server error Status code indicates that there was an error during
processing the request
3.1.7 Using cache in REST services
If we want to improve the overall performance of client and server, developers can use
different caching strategies to improve network usage and data retrieval. We can do this
by adding cache constraints in order to tell the client that he can reuse the data. When
we speak about cache control in REST, we are speaking about network level cache and
not application cache [64]. Response from the server has to be labelled as cacheable or
non-cacheable implicitly or explicitly.
26
The biggest advantage is the reuse of the data retrieved. Because it is a network level
cache, it addresses primarily improved interaction, efficiency, scalability, and overall user-
perceived performance. In terms of the disadvantages, the biggest one we must consider
is stale data. When we are using the cache as an optimization technique, we should take
into consideration that the data could be stale if we cache for too long a period of time.
It makes sense to cache the things we know are not going to change for a while, like a list
of countries, zip codes in a given country, etc. In order to prevent stale data and keep the
optimization, a shorter period of the cache must be used. The period of cache and cache
properties that a client can use must be directed to the server. In order to do so, the
server puts the properties in the cache control header of the response issued on behalf of
the client request.
Given that we have a low-level load on our services, there is no point in incorporating
cache control, but if we have thousands of users, even a low period cache can make all
the difference and improve overall performance. When we want our clients to cache the
response, we have to set the header in response, because, with a cache-control header,
we tell the client that the response can be cached [64]. With the cache control, we must
also provide additional information on how long the response shall be cached and when
the clients must refresh data. A cache control header is defined by the specification
HTTP/1.1.
As much as we want to implement cache, there are certain scenarios where we do not
want to cache resources at any means. Such scenarios include, for example: Payment
details, shopping basket at online store etc. For defining that cache should not be used on
a certain endpoint, we must use the Directive seen from Table 3.3 [64].
Table 3.3 - Caching header parameters
Header key Description Example
Cache-control Cache-control can be set to either public or private.
The difference between them is that, with the
public, any proxies on the path to the end client
can cache the response. Given that the value is
Cache-
Control:public,
max-
age=31536000
27
Header key Description Example
private, only the end client can cache the response.
Cache-control is a composite header that also
contains the timespan to cache the resource
Expires Even though the key cache-control contains
information about max age, this key provides the
information when the cached resource is no longer
valid. If both of the keys are set (max-age and
expires) the max-age will take the priority.
Cache-
Control:public
Expires: Mon, 25
Jun 2012
21:31:12 GMT
Last-Modified A key of the cache control header that states a
time-based conditional request. The request will be
sent only if the server confirms that a newer copy
of the resource exists. This field is used to store the
information about the last change of the resource.
If the client sends the last modified timestamp that
matches the one on the server it will not issue a
new request.
Cache-
Control:public,
max-
age=312336000
Last-Modified:
Mon, 05 Jan 2011
18:00:57 GMT
If-Modified-
Since
Every subsequent request that is cached and has
time-based conditional caching is using this key to
tell the server which version of resource he has. If
the server responds with the status code 304 then
the cached version is used. Alternatively, the server
can return a new version of the resource
If-Modified-
Since: Mon, 03
Jan 2011
17:45:57 GMT
ETag Given that we can have numerous services
deployed on different time zones and continents,
the time itself can become a problem. ETag can be
used to except the digested value of the resource,
which is then used to send to the server if a newer
version of the resource exists.
Cache-
Control:public,
max-
age=31536000
ETag:
"15f1ac18fff99ed
5aae4edffdd649”
If-None-Match Similarly, like Last-modified, this tag is used to
query the server for the new hashed version. If
28
Header key Description Example
server has the same it responds with status code
304 Not modified. Alternatively, it sends the new
version of the resource.
No-cache No-cache means that client must revalidate each
subsequent request with the server
Pragma:no-cache
No-store Tells the client that he mustn’t use cache on this
particular resource
Cache-Control:
no-cache, no-
store
3.1.8 Drawbacks of the REST architectural pattern
REST as an architectural pattern has several drawbacks that need to be considered.
1. Because of the stateless nature and client-server approach, the client has to send
additional information with every subsequent request made to the server;
2. There is no standard way of defining formal communication. In the SOAP service,
we can use Web Service Description Language (WSDL) to describe what endpoints
a web service is advertising and the means of communication with those
endpoints;
3. REST relies heavily on HTTP protocol and underlying security protocols;
4. In a REST architectural pattern a portion of security is passed to implementation
details of the API as opposed to SOAP, which is a part of substandard WS-
Security.
3.2 Transport layer security
Commonly known also by its abbreviation TLS and by its predecessor Secure Sockets
Layer (SSL) it is an IETF standardised cryptographic protocol used to provide secure
communication between two network endpoints. Currently, there are several known
versions of the protocol that supports many different purposes and applications, such as
email, web browsers, Instant Messaging (IM), Voice Over Internet Protocol (VOIP).
Transport layer security is used most commonly as a security pattern used by servers and
browsers to establish a secure communication channel between two respected parties
[66]. The main concern of TLS is to offer a secure channel of communication that ensures
prevention of eavesdropping ans tampering and, on the other side, offers privacy and
29
data integrity. TLS is an evolution that replaced Netscape’s implementation of SSL in
order to provide a more secure and efficient protocol that offers more supported chipper
suites, and key exchange algorithms that offer the use of more robust and secure ways to
communicate between endpoints. It is important to understand that, for that reason, TLS
and SSL are not backward compatible [66]. When a secure channel has been established
between a client and a server the secure channel offers the following properties:
1. Private (secure) communication;
2. Identity and authentication;
3. Data integrity.
3.2.1 Securing communication
TLS security ensures confidentiality and integrity between two parties. The connection
between two endpoints is secure because of a shared secret that is exchanged during the
handshake protocol and by the usage of symmetric and asymmetric cryptography that
encrypts the data transmission. Handshake protocol will be explained in detail in
subsection 3.2.3. Keys for the usage of symmetric cryptography are generated uniquely
for each connection at the beginning of session initialization. As stated, the server and
client have to negotiate security details before the first byte of communication is sent.
The client sends the list of supported chippers and the server chooses the strongest
cyphers available. If the server does not support any of the cyphers that the client listed
the communication is terminated. A shared secret between server and client is based on
the random number and session identification. The exchanging of a shared secret is also
secured either by a Diffie-Hellman algorithm, or the client encrypts a random number
with the usage of the server’s public key, and sends the encrypted result to the server.
The server decrypts the transmitted data and uses the random number to generate a
unique session key which both parties can use for further subsequent request encryption
[66].
3.2.2 Identity and authentication
SSL and TLS can provide identity and authentication on both server or client side. This is
achieved with the use of Certificate Authority (CA) issued certificates that are validated
through CA authorities. During the handshake protocol, the certificates are exchanged
and play a vital role in server definition and integrity. In general, CA authorities ensure
30
that the issued certificate belongs to a party that they know [66]. Transitively speaking, if
you trust the CA authority, and a server has a certificate that was issued by the given
authority, it implies that you can trust the server. When API wants a certificate to be
issued by a CA authority, it must prove that it is the rightful owner of the domain and
resource. Only after proving the given information, the CA authority issues a certificate
that a server can use and hand over to requested clients. This is important for the reasons
of forgery and promises.
Implementation speaking, the CA certificates contain a public key. The private key is given
to the resource owner, which he uses to decrypt information. The public key that is
stored in a certificate allows the client to encrypt data that only the server can decrypt
[66].
The TLS Standard is divided into two main parts. The first part defines the protocol itself
and defines communication flow (TLS Record protocol). The second part of the Standard
is called the Handshake Protocol and defines how two parties must negotiate the security
channel.
3.2.3 Handshake Protocol
The Handshake Protocol defines the part of TLS and SSL communication called the key
exchange that is necessary to establish a secure communication [67]. The Handshake
Protocol has three main parts that happen during the negotiation of security details. The
main parts are as follows:
1. Cipher suite negotiation;
2. Authentication of the server using a CA certificate;
3. Session key information, needed to provide a unique session identification for
each request.
All three main parts happen with the use of messages that the client and server
interchange during the handshake. If all the steps are met, the secure connection can be
established [67]. In Figure 3.1 we can see the detailed exchange of all information
between initialization of the TLS protocol.
31
Figure 3.1 - Graphic representation of the Handshake Protocol [65]
3.2.4 Cipher suite negotiation
The client and server need to agree on which cypher suite they will use during the
communication and how will they use it. Cipher suite negotiation begins with the client,
who sends a list of supported cyphers in order of preference. The server picks up the
most secure cypher it supports and sends back the information to the client. If a server
does not support any of the cyphers that the client sent, the Handshake Protocol is
terminated, and the secured channel cannot be established [67]. It is possible that
different requests agree on different security parameters used during communication.
3.3 Javascript Web Token
JSON Web Tokens, or JWT for its abbreviation, are RFC Open Standard (RFC 7519) for
passing information securely, known as claims between two parties, usually a server and
a client. Data and information can be transported securely and verified using digital
signature and encryption algorithms. JTWs follow a structured approach by following
JSON Standards and are encoded for transportation over the internet using base64
algorithms [38]. The main focus for the Standard has been the implementation of a
technology or a concept that produces small and compact textual information and makes
use of already existing Standards as much as possible. The most important aspect has
been following the REST stateless derivative. In order to achieve stateless
32
communication, the JWT is supposed to be self-contained and include all the information
that a certain party needs to complete the request [39].
JWT tokens are used primarily for two main reasons:
1. Authentication;
a. To propagate one’s identity between interested parties;
b. To propagate user entitlements between interested parties;
c. To assert one’s identity, given that the recipient of the JWT trusts the
asserting party;
2. Information and data exchange;
3. Transfer data securely between interested parties over an unsecured channel
[38].
Authentication
This is the most common practice and use-case for JWT tokens. The client itself exchanges
the user credentials for a security token, which is then used by every subsequent request
sent to the server. The server receives the token, checks the digital signing and decrypts
the encrypted information [38]. JWT also has a validation period which the server checks
first. In order to complete the request fully, the JWT has to have a valid date and needs to
be signed properly using the server`s digital signature algorithm and secret key.
Information and data exchange
JWT can also be used in order to transmit sensitive data between two parties. The main
benefit is the digital signature, that ensures that information has not been tampered with
between the transmissions [38]. The main drawback we need to consider is the size of
data we put into JWT tokens. If we have a lot of communication between two parties, the
size of the token can impact the performance of request execution.
Two main types of JWT exist:
1. Json Web Signature (JWS);
2. Json Web Encryption (JWE).
33
In order for a better understanding, we can think of JWT as an abstract implementation,
and JWS or JWE as a concrete implementation, as seen in Figure 3.2. The main difference
between them will be examined further in the following subsections.
Figure 3.2 - JWT type definition
3.3.1 JWT token structure
A JWT token consists of three main parts that are separated by a dot (».«) delimiter. The
main parts are defined as [38]:
1. Header;
2. Payload;
3. Signature.
The structure of JWT can be represented at the following format:
header.payload.signature
The header part of the JWT, seen in Figure 3.3, consists of information regarding the
hashing and encrypting algorithms that are being used along with the payload and
signature. The header defines the specific type of token and any additional information
that is required to process the JWT token [38]. Implementation must understand the
header information completely, otherwise, the JWT token should be rejected for further
processing in order to drop malicious requests.
34
Figure 3.3 - JWT Header [30]
The content of the header is encoded for transport using base64Url encoding algorithms.
Followed by the header information, the payload, as seen in Figure 3.4, is a part of a JWT
token that consists of information about a certain entity. Usually the entity is
represented as a user and information regarding it. Information about the entity is
defined as claims, and there are three different types of claims we must consider.
1. Reserved claims;
2. Public claims;
3. Private claims.
Reserved claims are predefined by a Standard and define metadata regarding handling,
issuing and domain of the JWT. Reserved claims are not mandatory. Public claims can be
defined by those using JWT tokens but, in order to avoid a collision, they have to have a
unique namespace definition, or be defined in the IANA JSON Web Token repository [38].
Private claims are custom claims that are application specific, and are agreed on by both
parties that use them. Further examination of JWT claims is provided in paragraph 3.3.2.
Figure 3.4 – JWT Payload example [30]
Payload is also encoded for transport using base64Url encoding algorithms. A base64Url
encoded payload represents the second part of a JWT token [39].
35
The last part of a JWT token structure is the signature. A signature is a computed part of
a JWT token that consists of:
1. A base64Url encoded header and payload;
2. A given secret;
3. Algorithm of signing.
Figure 3.5 - JWT Signature example [30]
The main purpose of the signature is to provide integrity protection, which ensures that a
JWT token has not been tampered with in the transportation and communication
between two parties. It also serves as an identifying mechanism for the client [38].
If we now put all of the parts together (header, payload, and signature), we get the full
structure of the JWT, presented in Figure 3.6.
Figure 3.6 - JWT Compact structure [30]
In Figure 3.6, coloured red we see the Base64URL encoded header part of the JWT. Just
after the dot delimiter, the purple part is the Base64URL encoded payload, followed by
the Base64URL encoded signature part.
3.3.2 JWT Claims
As defined, claims are information regarding a certain entity that is application specific.
Usually, it identifies the user, but it is not mandatory [38]. We will examine further the
36
three main types of claims, and provide additional information of reserved and public
claims.
3.3.2.1 Reserved claims
Reserved claims are claims that are by predefined by the Standard itself. Reserved claims
are not mandatory, but provide a set of useful and interoperable claims. Such claims
provide information about the following;
1. Iss (issuer);
2. Exp (Expiration time);
3. Sub (Subject);
4. Nbf (Not before);
5. Aud (Audience);
6. Iat (Issued at);
7. jti (JWT ID).
Issuer
The issuer claim is proposed for the usage of proclaiming the information about the issuer
of the token itself. An issuer reserved claim is optional, and processing of these claims is
application specific. An issuer claim is case sensitive and JSON string type is expected [38].
Expiration time
The expiration time claim is proposed for the expiration time after which the token
should not be processed anymore. The value of the exp parameter should be lower than
the current date and time. The claim is optional, and expects a JSON number type [38].
Subject
The claims in JWTare focused around a given subject. This claim is responsible for
declaring the topic of payload information. The subject value should be scoped a unique
value in the context of the local environment or be defined as globally unique. The
subject field is optional and defined as a JSON string type [38].
37
Not before
A not before claim is intended to provide information about the time that the token
should not be processed. The value of a »not before« claim should be after the current
time. The claim is optional and expects a JSON number type [38].
Audience
An audience claim represents the value that describes uniquely for whom the JWT token
is intended. Every time a certain implementation tries to process a JWT it must identify
with the value provided in the audience claim. Otherwise, the processing of the JWT
token should be rejected. An audience claim is optional, and can be presented as an array
of JSON string type or a single value. The purpose and processing of an audience field is
application specific [38].
Issued at
Represents the exact time that the JWT was created. The intention of this parameter is to
calculate the age of a JWT token. The usage of this claim is optional and the value must be
a JSON number type [38].
JTI – JWT identifier
JTI is a unique client identifier number for the JWT. The value has to be globally unique
and the issuer must ensure that the same identification number is not assigned to any
other data object or JWT respectively. The purpose of JTI can be either to revoke a certain
token associated with a client, or to prevent a JWT from being replayed and reused with
malicious intents. The value of JTI is a case-sensitive JSON String type and the claim is
optional [38].
38
Figure 3.7 - Reserved claims example
3.3.2.2 Public claims
Public claims are claims that define certain parameters for standardization of
interoperable metadata between services. Such parameters include name, email, or
address. Public claims are defined in the IANA JWT Claims Registry [38].
3.3.2.3 Private claims
Private claims are custom claims that are application specific, and are not part of the
standardization. Private claims should not interfere with public or reserved claims. The
processing of private claims should be defined by both parties before the initiation of the
communication flow [38].
3.3.3 Standardization
Standardization of JWT tokens consists of multiple proposed RFC Standards. Each of them
is responsible for specifying a certain subgroup of implementation and concept.
Substandard are as follows:
1. Json Web Encryption (JWE);
2. Json Web Key (JWK);
3. Json Web Signature (JWS);
4. Json Web Algorithms (JWA).
39
3.3.3.1 Json Web Encryption
Also known by its abbreviation, JWE is a sub-Standard of IETF defined by the number RFC
7516. The sub-Sstandard was submitted by M. Jones, J. Bradley, N. Sakimura, Microsoft,
Ping Identity, NRI, in May 2015. The main purpose of the JWE Standard is to address the
serialization and encryption of the content that is transmitted between two parties. A
JWT token itself, by default, is not encrypted, but only encoded. Encoding is done using
base64Url encoding algorithms. However, if we want to add another layer of security on
our tokens, we can encrypt the token using symmetric or asymmetric encryption
algorithms with the use of the shared key or public-private key pairs [40]. Cryptographic
algorithms are not part of this sub-Standard but are defined separately in the JSON Web
Algorithms sub-Standard.
Two closley related serializations are defined:
1. Compact serialization;
2. JWS JSON serialization.
Compact Serialization is a compact, URL-safe representation intended for space-
constrained environments such as HTTP Authorisation headers and URI query parameters
[40]. Compact serialization can be seen in Figure 3.6.
The JWS JSON Serialization represents JWSs as JSON objects and enables multiple
signatures and/or MACs to be applied to the same content [40]. JWS Json serialization
can be seen in Figure 3.9.
3.3.3.2 Json Web Key
JSON Web Key, or JWK for short, is an IETF sub-Standard of JWT defined by the number
RFC-7517. The sub-Standard was proposed by M. Jones and Microsoft in May, 2015. Sub-
Standard defines JavaScript Object Notation (JSON) data structure with the
representation and information about the cryptographic key [41].
40
Figure 3.8 - JWK example [31]
Sub-Standard also defines a set of JWK and JSON data structure in order to define
multiple properties regarding signing and encryption of a JavaScript web token. A JSON
Web key has a set of predefined claims:
1. "kty" (Key Type) Parameter;
2. "use" (Public Key Use) Parameter;
3. "key_ops" (Key Operations) Parameter;
4. "alg " (Algorithm) Parameter;
5. "kid" (Key ID) Parameter;
6. "x5u" (X.509 URL) Parameter;
7. "x5c" (X.509 Certificate Chain) Parameter;
8. "x5t" (X.509 Certificate SHA-1 Thumbprint) Parameter;
9. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint).
Key type parameter
The key type defines which algorithm family is used in combination with the key, for
example, »RSA« or »EC«. The algorithm must either be registered in the Internet Assigned
Numbers Authority (IANA) in the repository of JSON Web Key Types, or be a value that
contains a Collision-resistant name. A collision resistant name is hard to achieve, because
it should be globally unique for the issuer – the company. The value is proposed as a
String type and it is formally case-sensitive. The key type parameter is mandatory as
defined by the Standard [41].
41
Public key use parameter
The Key use parameter defines the intended use of the public key. The »use« parameter
indicates if the public key is used for encrypting the data transmission or verifying the
signature [41].
Key operations parameter
An alternative for the public key parameter is the usage of the »key_ops« parameter. The
parameter defines the operation for which the key is intended to be used. The main
difference from the public key parameter is that the key operations parameter defines
specifically the use when public, private or symmetric keys are to be present. Both
parameters, »use« and »key_ops«, should not be present at the same time. If we use
both, the information provided should be consistent. The value of the key is defined as an
array with a predefined set of values that can be used. These values include:
1. Sign (computing digital signature);
2. Verify (verifying digital signature);
3. Encrypt (encrypt content);
4. Decrypt (decrypt content and validate decryption);
5. WrapKey (encrypt key);
6. UnwrapKey (decrypt key and validate decryption);
7. DeriveKey (derive key);
8. DeriveBits (derive bits is not to be used as a key).
The key operations parameter is not mandatory. Other values apart from defined one in
the specification can be used, although these values should be application specific [41].
Algorithm parameter
Algorithm parameter defines the algorithm that is to be used with the key. The value
should be defined in the IANA JWT Signature and Encryption Algorithms repository, or a
value that is collision resistant [41].
Key id (key identifier)
Key identifier parameter defines the identification number in pair with a certian key.
Identification number can be used when multiple keys can be present. Identification
42
number should be unique for every key definition. The value of key identifier should be a
case-sensitive JSON String. Use of the key identifier parameter is optional [41].
3.3.4 Json Web Algorithms
Also, known by its abbreviation, JWS is an IETF Standard with the number RFC 7518. It is a
proposition of a Standard, a draft, which was submitted by M. Jones, Microsoft, on
January 13, 2015. JWA defines algorithms, identifiers and IANA registries for
cryptographic and signature keys to be used alongside JWS, JWE, JWK Standards. The
main purpose that algorithms and identifiers are extracted from these Standards is
because they change frequently over time and in such a way that the Standard can
change without effect on the JWS, JWE and JWK Standards. Authors have, in a way,
decoupled algorithms from the main Standard definition [42].
3.3.5 Json Web Signature
Also known by its abbreviation, JWS is an IETF Standard with the number RFC 7515. It is a
proposition of a Standard, a draft, which was submitted by M. Jones, J. Bradley, N.
Sakimura, Microsoft, Ping Identity, NRI, in May 2015. The proposed sub-Standard defines
how content and payload should be signed with digital signatures or MAC using JSON-
based data structures [43]. The main purpose of the JWS proposed Standard is to provide
mechanisms for integrity protection. Integrity protection is important, so that parties
know that a token has not been tampered with during transmission and communication
using techniques such as MITM. The signature can be a part of compact serialization, or
defined as JWS JSON Serialization [43].
43
Figure 3.9 - JWS JSON Serialization [32]
3.3.6 Authentication and communication flow
When a user wants to obtain a JWT token he needs to exchange his credentials, like
username and password, for a valid token. Before sending credentials, a secure channel
of communication must be established, like TLS and SSL. A secure channel prevents any
tampering with and interception of data using MITM attacks. On successful login, the user
obtains a valid JWT token. The token itself should be stored on the client. Storage can be
either a local storage or a cookie. Cookies are, in JWT context, just a storage technology,
and serve no purpose as a session in communication flow. Whenever the user wants to
access protected resource, the user should send along JWT with every subsequent
request. He can do so by using the »Authorisation« parameter of a HTTP header or send a
cookie alongside the request. This concept and HTTP request with authorisation header is
presented in Figure 3.10. The processing of JWT is application specific. If the JWT is sent
using the authorisation header parameter, it should follow the bearer schema.
44
Figure 3.10 - JWT Authorisation header parameter
JWT tokens are, by definition, compact and self-contained, which means that all
information required to process authentication should be stored in the JWT itself.
Therefore, any query to the database or local cache should not be required.
Figure 3.11 - JWT Authentication and communication flow [30]
In Figure 3.11 is presented the whole communication flow in which a client, browser,
obtains an access JWT token and sends it in an authorisation header to prove his identity.
In the first step, seen in Figure 3.11, the browser issues an HTTP POST request with user
credentials – username and password. A common scenario representing step 1 in Figure
3.11 would be a login form where the user enters his credentials. The server accepts the
requests and verifies user credentials against stored information. If the credentials are
correct, the server issues a JWT with claims and signs the JWT with the provided
45
algorithm and a secret key. Next, the server returns the JWT, which the client receives
and stores in local client storage or a cookie. With every request the client makes, a client
has to retrieve a token from the provided storage and send along the request. This can be
seen in step 4 of Figure 3.11. The server, before it starts processing the requests, verifies
the token by checking the signature, provided claims and expiration date. If the token is
valid, the server proceeds to issue the request, otherwise the request is terminated. How
the server responds to the termination of request is defined as application specific.
Furthermore, we must address that is not necessary for a client to be a browser, as seen
in Figure 3.11. Any sort of client would have the same communication flow.
3.3.7 Critical vulnerabilities in JWT tokens
As of March 31, 2015, Tim McLean has discovered critical vulnerabilities in JWT Standards
and implementation libraries and frameworks. As we already defined in paragraph 3.3.1,
the JWT token consists of three parts (header, payload, signature). The problem becomes
obvious when we want to verify a token. The steps required to verify the token are as
follows:
1. Extract the header part of the JWT;
2. Decode the header;
3. Check the value of “alg” reserved claim that defines the algorithm used for
signature;
4. Use the value of the algorithm and provided secret to verify the token.
In order to verify the token, we give the attacker an option to tell which algorithm to use
to verify the token. This should not be a problem since, if an attacker provides an
algorithm that was not used for singing, the token is invalid during verification [44].
The problem becomes when the attacker uses the value “none”. The value “none” of an
alg claim is proposed by Standards as a value that is intended for providing the
information that the token has already been verified. In that manner, the implementation
of libraries and frameworks around the JWT Standard has treated every token with the
value of “alg” claim - none, as valid and verified [44].
46
This imposed a security issue and vulnerability that has been discovered and fixed and
most have already been verified. In that manner, the implementation of libraries and
frameworks around the JWT Standard has treated every token with the value of “alg”
claim - none, as valid and verified. This imposed a security issue and vulnerability that has
been discovered and fixed in most libraries [44].
3.4 OAuth 2.0
OAuth 2.0 is an authorisation protocol defined by the RFC-6749 Standard on the IETF
Institute. The main definition was proposed by D. Hardt, Ed.and Microsoft in October
2012 [55]. The purpose of the OAuth 2.0 protocol is to allow applications access to a
limited set of information about a certain subject, usually user information, from third
party applications such as Facebook, Google, Github. It does so by orchestrating user
approval, or allowing an application to access data on third-party applications on their
behalf. OAuth 2.0 supersedes the previous definition of protocol OAuth 1.0, and is
defined as a completely new protocol that is not backward compatible; however, OAuth
2.0 retained the overall architecture of OAuth 1.0.
3.4.1 OAuth 2.0 protocol roles
In order to understand the authorisation flow, we have to define roles specified by the
OAuth protocol. OAuth defines four main roles [56]:
1. Resource owner;
2. Resource server;
3. Client;
4. Authorisation server.
47
Figure 3.12 - OAuth 2.0 roles [32]
3.4.1.1 Resource owner
Resource owner is defined as an entity that is capable of authorisation access to the
protected resource [56]. When this entity is a person, the resource owner is defined as an
end-user, as seen in Figure 3.12.
3.4.1.2 Resource server
Resource server is a server that holds information of the resource owner. A resource
server is capable of serving resource owners data by validation access tokens [56].
3.4.1.3 Client
Client in OAuth 2.0 is defined as an application that is making a request to the resource
server by using the resource owner’s permission. The definition of client in OAuth 2.0 is
not implementation specific [56]. In that way, a client can be a mobile, web or desktop
application.
3.4.1.4 Authorisation server
Based on user approval, the authorisation server is responsible for issuing an access token
that a client can use in order to access protected resources [56].
3.4.2 OAuth 2.0 protocol flow
By defining roles in paragraph 3.6.1, we can now define the interaction between them
and show the protocol flow that is involved using these roles. The graphical
representation of the protocol flow is shown in Figure 3.13. The protocol flow has defined
steps as the following procedure:
48
1. The application (defined as a client) requests an authorisation grant from the
resource owner – usually the user. This can be done directly by resource owner
initiation, or indirectly by authorisation server request;
2. The client receives the authorisation grant from the resource owner, which serves
as a credential representing the resource owner's authorisation;
3. The client requests from the authorisation server an access token by
authentication with grants provided by the resource owner;
4. The authorisation server checks if the client is valid by verifying client and
validating provided authorisation grants. If both are valid, the authorisation
server issues an access token;
5. The client requests the information from a protected resource by providing an
access token alongside the request;
6. The resource server validates the access token. Upon successful validation, it
responds with provided information about the resource owner [57].
Figure 3.13 - OAuth 2.0 protocol flow [33]
3.4.3 OAuth 2.0 Authorisation grants
An authorisation grant represents a resource owner's authorisation for accessing data on
a third party application. It is considered a proof that the resource owner agrees that the
client can access information stored on the resource server by exchanging an
authorisation grant for an access token. The specification proposes four different grants,
49
depending on the model of authorisation and technology used [58]. These grants are as
follows:
1. Authorisation code;
2. Implicit authorisation grant;
3. Resource owner password credentials;
4. Client credentials.
3.4.3.1 Authorisation code grant
An authorisation code is obtained by using an authorisation server as an intermediate
between communications of authorisation. As seen in Figure 3.14, instead of direct
authorisation from the resource owner, the client redirects the user to the authorisation
server, which, upon authorisation, redirects back to the client with the additional
authorisation code. Redirection is supported by using a user-agent (browser) [58].
Before redirecting back to the client, the authorisation server authenticates the user and
obtains authorisation. The resource owner, before the authorisation, does not
communicate through the client, thus the resource owners’ credentials are never
exposed to the client [58].
Figure 3.14 - Authorisation code grant protocol flow [27]
50
3.4.3.2 Implicit authorisation grant
An implicit grant simplifies the authorisation flow by exchanging an authorisation grant
for an access token directly to the resource owner, instead of obtaining an authorisation
code which the client can later use for obtaining the access token. The implicit flow is
intended mostly for clients’ implemented using browser using fronted language such as
javascript. An example of such application is a single page web application. Implicit flow
offers optimization, and improves responsiveness and efficiency on a level that reduces
the number of round-trips required to obtain the access token which is required to access
information on the resource servers. The optimization comes with the trade-off of
possible security flaws. Because the access token is issued to the resource owner directly,
it can be intercepted and used as an impersonation of the resource owner. In
authorisation code grant, the client exchanges the authentication code for the access
token. When the exchange happens, the authorisation server validates the client before
issuing the access token. This step does not happen in the implicit grant [58].
3.4.3.3 Resource owner password credentials grant flow
Client credentials grant flow should be used only when a high degree of trust has been
established between resource owner and client . A high degree of trust can mean, for
example, that a client is a part of device operating system or is a high priority application.
Resource owner credentials flow should only be used when there is no other possibility of
using another type of grant [58]. The client should use resource owners’ credentials only
once to obtain the access token. Because the access token is short lived, the client should
use the refresh token to obtain a new access token, thus eliminating the need to store
resource owners’ credentials.
3.4.3.4 Client credentials grant flow
Client credentials grant is intended to be used when a client is also a resource owner and
acting on its own behalf, or the client is accessing protected resources based on a
prearranged grant [58].
3.4.4 Accessing protected resources
Accessing protected resources on a resource server can be achieved by using tokens.
There are two types of tokens we need to consider when working with OAuth 2.0 [58]:
1. Access token;
51
2. Refresh token.
3.4.4.1 Access token
The access token is a string representation of a resource owner authorisation grant.
Based on the type of grant, the client exchanges the authorisation grant for an access
token, which can then be used to access protected resources hosted on the resource
server. The access token is an abstraction layer that is replacing the need for passing
credentials of a user. Access tokens are short lived and are issued by an authorisation
server [58].
3.4.4.2 Refresh token
The role of refresh token is to obtain another access token when it expires. Refresh
tokens are only used by an authorisation server and never on a resource server.
Depending on the grant type when the authorisation server issues an access token, it also
provides a refresh token, which has a longer lifetime span. When a refresh token
becomes invalid, a resource owner has to provide another grant, which the client can
then use to obtain another pair of access and refresh tokens [58].
Figure 3.15 - Using refresh token flow [59]
3.4.5 OAuth 2.0 client registration
Before the first communication between client and authorisation server is established the
client has to register with the authorisation server. Registration of a client is not defined
by the specification, but is typically done by using registration forms. For example, to use
Google API services such as Google Drive or Google Maps, and in order to access user
52
data, you have to register your client to the Google API console, which can be seen in
Figure 3.16.
Figure 3.16 - Google API console
By registering the client, the developer should provide information about:
1. Client type, as defined in subsection 3.4.6;
2. Define client redirection URI that a client will follow after providing an
authorisation grant;
3. Provide additional describing information about the client itself, like logo of the
client, home website, legal information site etc.
By registering, the client obtains a unique client identifier. A unique client identifier is a
string representing the information provided by the client developer. The client identifier
alone is not enough for client identification, because it can be exposed to the resource
owner. Possible client authentication techniques are described in subsection 3.4.7.
3.4.6 OAuth 2.0 client types
OAuth 2.0 defines two main client types that can occur. These two client types are
defined by their ability to authenticate securely to the authorisation server. Two types are
defined as:
1. Confidential client;
2. Public client.
53
It is important to authenticate the client to prevent impersonation attack during the
implicit grant. If the attacker somehow manages to obtain the authentication code, he
can exchange it for an access token with the authorisation server. Authentication of the
client helps resolve this issue by offering the client another layer of security to present
himself uniquely [60].
3.4.6.1 Confidential client
Confidential clients are clients that are capable of maintaining their confidentiality. This
means that the client is either a secure server, or a client is capable of securing
credentials by any other means possible [60].
3.4.6.2 Public client
The public client is a client who cannot manage security credentials in order to
authenticate to an authorisation client. This client can be native applications, applications
installed on a resource owner’s device (mobile devices), or web browser-based
application like a single page application.
3.4.7 Client authentication
As stated in subsection 3.4.5, in order to initiate the OAuth 2.0 protocol with an
authorisation server, the client developer needs to register the client with the
authorisation server and obtain a client identifier. However, the client identifier is not
enough to authenticate a client securely [60]. In order to provide an additional layer of
security, a client can authenticate using the client password that was issued by the
authorisation server by client registration or using private/public key-pairs [61].
3.4.7.1 Client password authentication
A client who has obtained a client password can issue the HTTP Basic authentication to
authenticate to the authorisation server. In order to authenticate, the client has to
provide two things:
1. Client identifier as described in 3.4.5;
2. Client secret – also obtained by the registering client.
Both client identifier and client secret must be encoded using the application/x-www-
form-URL-encoded encoding algorithm. Client identifier serves as the username and
client secret as the provided password [61].
54
3.4.8 Other methods of authenticating clients
An authorisation server can provide other methods of authenticating users but, in order
to so, the mapping between client identifier and method used must be declared [61].
3.4.9 Serving unauthenticated clients
An authorisation server can serve unauthenticated users, and specification does not
exclude serving the unauthenticated client. When the authorisation server administrators
and developers decide to serve an unauthenticated client, they have to consider the
security risk that is involved with that decision. Security risk differs from the type of client
that will connect [61].
3.5 Session management, JWT and OAuth 2.0 comparison
During this section, we will provide a comparison of session management, JWT, and the
OAuth 2.0 protocol, and introduce the advantages and disadvantages when using a
certain approach.
3.5.1 Session management
Session management provides a simple implementation on the server side and on certain
client types like browsers as well, and it is a proven technique that was developed and
improved over the years of development. When a user performs logout, the session is
discarded easily from the pool of the active session. The biggest drawback that we need
to consider when implementing using session management is that holding a lot of
sessions in memory or in local storage can use a lot of resources, thus causing
performance and responsiveness penalties. Because not every user performs logout, for
the server to know when to invalidate certain sessions, the server has to check for
expired sessions periodically and remove them. Furthermore, every HTTP request
requires local storage or database access. Session management is the perfect approach
when we want to delegate the user authentication and authorisation security to the
application server.
3.5.2 JWT
With the use of JWT, there is no need to keep the state on the server side, since JWT
carries all the information needed for the client to prove his identity and authorisation.
55
Furthermore, the use of JWT brings easier implementation of user authentication and
authorisation on a variety of technology independent clients. When implementation of
JWT is used, we need to consider the size and amountof information we put into the
token itself. Since the token is sent using every subsequent request, the size of the token
can affect the performance of transmission and token processing directly. If the issued
token is not encrypted, only encoded, the information stored in the token can be read on
the client side. Compared to the session management, the application server has no built-
in support for token issuing, validation, and invalidation of tokens. This means that a
developer has to do a custom implementation of token lifecycle management, which can
impose security vulnerabilities if it is not done correctly. JWT is a good approach when we
communicate completely stateless and want to implement a custom solution of token
verification, issuing and revoking.
3.5.3 OAuth 2.0
OAuth 2.0 provides, for users, a convenient way of logging in into the application without
providing credentials. However, the specification of OAuth 2.0 does not provide any
information how a client, an application in terms of OAuth 2.0, should verify the access
token. Given that there is no formal specification means that every platform can impose
its own rules which we need to consider for the token verification. Furthermore, there is
no unified usage of the protocol, which means we have to provide many different
implementations if we want to support different platforms like, for example, Google,
Facebook, Dropbox etc. Another thing we need to consider is that we are delegating user
authentication and authorisation to third-party applications. A nontechnical drawback we
need to consider is privacy concerns. Because the user is taking advantage of third-party
platforms for authorisation, it means that the third-party platform is aware of what
applications a user is using. Third-party applications are also aware of how many users are
using a certain service.
56
3.6 Summary
During this chapter, we have provided a broad overview of the technical details needed in
order to achieve secure token issuing, accessing protected resources, and technical
details in relation to reissuing and obtaining new tokens. We have also provided technical
details about communication flow, and securing the transmission from the client to the
server. We have shown how to provide an additional layer of security by applying
encryption to the token. Furthermore, we have addressed the philosophy regarding the
implementation of API using REST fundamental principles, and what it means in practice
to follow these principles.
57
4 IMPLEMENTATION DETAILS, DESIGN AND TESTING
In this chapter, we provide technical details about the implementation by specifying the
architectural design, communication flow, use case diagrams and technologies used and
the reasons behind the decisions.
4.1 Proposed solution
The dissertation will address the implementation of the REST web service API that is
designed and implemented using REST fundamental concepts, horizontal scalability
ready, and ensured secured transport channel using SSL/TLS. Furthermore, technologies
and frameworks that must be used to achieve as little downtime as possible, and how the
configuration of server instances needs to be done in order to be as secure as possible.
The dissertation will also address user authentication and authorisation using frameworks
and concepts around JWT and OAuth 2.0. Token life cycle management on the mobile
application will also be addressed, with details provided about safe storage, token
retrieval and refreshing. The solution will focus on solving problems that musicians face
when organising music
The problem derives from musicians handling lots of sheet music when preparing for a
certain performance. Professional musicians rely mostly on sheet music as a visual aid
which helps them remember different songs more quickly and efficiently during playing.
In that sense, the compositions and order of the songs need to be correct for every
musician playing in the ensemble or orchestra. If a quick assumption is made, that every
song lasts 4 minutes and each performance will last one hour with no interruptions, 15
songs will be played within that time. If another assumption is made that every song has
at least two pieces of sheet music, 30 pieces of sheet music are used per performance.
These papers need to be prearranged and structured. Often the order of the song is
changed or the playlist is rearranged just before the performance to adapt to a specific
audience. Another problem is turning the sheet music pages during the performance.
When musicians play they use both hands to play the instrument and cannot turn a page
when required.
58
Technical details will be provided from frontend and backend implementation, and also
managing and securing the application using cloud instance from a chosen cloud
platform. Token user authentication and authorisation tokens will be done using the most
popular technologies (JWT, OAuth 2.0).
4.2 Functional requirements and application definition
During this section, we will cover application definition by providing functional and non-
functional requirements.
4.2.1 Application definition
Our prototype android application tends to solve given problems by offering a solution
that enables musicians to photograph a piece of sheet music. The picture of the sheet
music is OCR scanned and helps with recognition of the composition, and provides
metadata about the song itself. The musician can now reorganise tunes easily and have
the ability to synchronise the playlist among other devices that musicians possess, or
share the playlist to other musicians. The application will be named Maestro Amadeus.
4.2.2 Functional requirements
Application full functionality specification is defined as followed:
1. Listing saved songs / notes;
2. Addition of new songs / notes;
3. Listing saved playlist;
4. Creating new playlist;
5. Playing a playlist;
6. Playing a single song;
a. If a single song has more than one piece of sheet music, the page turning
can be triggered using a Bluetooth device or pedal that is capable of
Bluetooth device technologies.
7. Playlist synchronization between devices;
59
The application itself is made for tablets running on the Android platform, but can also be
used as a mobile application. In order to clarify further we have provided a use case
diagram, as seen in Figure 4.1.
Figure 4.1 - Use case diagram
4.2.3 Technical requirements
Application technical requirements can be defined with the following requirements:
1. The server side solution needs to be able to serve multiple technology
independent clients;
2. The server side solution needs to be secured by issuing JWT tokens;
3. The Android application needs to be able to integrate with third party services
using the OAuth 2.0 protocol;
4. The server side needs to provide a secure communication channel using TLS/SSL;
5. The server side needs to be scalable, elastic and adaptable to user growth;
60
4.3 Market analysis of existing solutions
In this subsection, an examination of the market is outlined with mobile applications that
already try to solve the problem or the domain of the problem. The focus is based on
mobile applications that cover the domain of music and work as musician assistants.
Other criteria used for selection are applications that enable social sign using the OAuth
2.0 protocol.
1. Orpheus Sheet Music (FREE/PRO)
Orpheus is an Android mobile application that helps musicians organise sheet
music into set lists and music folders. Its primary advantage is Dropbox
synchronization and hands-free page turning using external accessories such as an
external Bluetooth pedal [6]. It offers a really clean, simple and easy to use user
interface. It was implemented for the Android platform with a minimum
supported version of system 4.0. The application has been available since 2015,
and, since the release of the application, users have downloaded the free version
of the application between 10,000 and 50,000 times, and the professional version
between 1,000 and 5,000. The professional version has currently on the Android
market a rating of 3.6 out of 5 with 128 reviews. The free version has the same
rating with 77 reviews. Currently, the price for the professional version is set at
4.43€.
61
Figure 4.2 - Orpheus Android application [6]
2. Mobile Sheets Music Reader (FREE/PRO)
It is one of the first Android-based applications on the market that offers sheet
music organisation. The minimum required version of the Android operating
system is 2.3. The application has been available since 2011. The current version
for professional use is 1.8.7 and 5.7.1 for the free version. The application has a
rating of 4.7 out of 5 for the professional version with 785 reviews, and 3.7 for the
free version with 537 reviews. The price for professional version today is 14.99€.
The application offers a lot of different functionalities for sheet music
organisation, such as arranging sheet music into groups/playlist, annotation of
sheet music for custom notes, playing with the use of metronome, and playback
of Musical Instrument Digital Interface (MIDI) files. However, the application does
not offer a Bluetooth device pedal, playlist and song sharing and OCR scanning of
sheet music to provide additional information.
62
Figure 4.3 - Music Sheet Android application [7]
3. MuseScore
MuseScore enables its user to find and discover new music through listening to
Musical Instrument Digital Interface (MIDI) files alongside sheet music. It can also
adjust tempo, and play or sing along using the parts mixer [18]. The application
was developed for the Android platform with a minimum required version of
mobile operating system 4.1. The application has been available since 2013 and
the current version of the application is 1.12. The application is rated at 4.2 out of
a possible 5, with 11,023 reviews till today. It has a staggering number of
downloads, between 500,000-1,000,000. The application is free to use. MuseScore
is a music practice application, and offers no sheet music organisation or playlist
sharing, or integration with a Bluetooth device pedal.
63
Figure 4.4 - Muse Score Android Application [8]
4. SongBook
SongBook allows users to manage songs with lyrics and/or sheet music, playback,
MIDI files and videos. It is a mobile application that allows the creation of a playlist
and offers the ability to organise songs in a certain order. Furthermore, it allows
users to annotate sheet music or song lyrics for later use [19].
Figure 4.5 - Songbook mobile application
64
The Songbook application is intended for the Apple iOS operating system. The current
version of the application is 3.1.4 and has been available since 2016. Minimum
requirement of the iOS operating system is 9.3 and has a price of 45$. The application,
however, offers a really complex user interface that is hard to adopt, no playlist sharing
through Google Drive integration, and no Bluetooth connection for device pedals.
4.3.1 Functional comparison of applications
Table 4.1.1 provides a functional comparison of the application based on the platform,
price and limitations.
Table 4.1 - Comparison of music applications
Name Platform Price Limitations
Orpheus Sheet Music PRO Android 4,43€ No google drive integration,
No device synchronization,
No OCR scanning of sheet music,
No playlist sharing
Mobile Sheets Music Reader Android 14.99€ No OCR scanning of sheet music,
No Bluetooth device connection
MuseScore Android Free No sheet music organisation,
Practice application,
No device synchronization,
No playlist sharing,
No OCR scanning of sheet music
SongBook iOS 45€ Complex for user adaptation,
No Bluetooth integration,
No Google Drive integration,
No OCR scanning of sheet music
65
4.4 Architectural design
In order to fulfil the technical requirements given in subsection 4.1.3, we have chosen a
micro service architecture with provided design pattern called API gateway. Micro service
architecture does not have a formal definition or correlated Standard, although Adrian
Cock, the Director of Web Engineering, and then Cloud Architect at a company called
Netflix, presented a quite clear explanation as:
»service-oriented architecture is composed of loosely coupled elements that have
bounded contexts.« (Tony Mauro, 2015).
Loosely coupled is defined as a term that any one updating service does not require
changing any other service. The term bounded context refers to services being
responsible for a subset of information about a certain domain and nothing more.
4.4.1 API Gateway pattern
API Gateway pattern is described as the architectural pattern that serves as a single point
of entry for the given client. The benefit we get when using API Gateway pattern is that
security is managed from one point, since this is the only Web Service that is exposed to
the public domain.
Figure 4.6 - API Gateway pattern [45]
66
Furthermore, the API Gateway service can serve as an aggregation point for other
services. The pattern is similar to the Facade software pattern. The API Gateway service
can also serve as:
1. Authentication and authorisation management;
2. Load balancing;
3. Response caching;
4. Provide health checks and monitoring;
In Figure 4.7 we present the architectural design of our implementation. The only client
accessing our services is, till now, Android Application, but that can change in the future
so we need to keep this in mind. The communication flow is supported by the use of the
API gateway service pattern, which we explained thoroughly in subsection 4.4.1. Nginx
software is used for subdomain translation and client redirection from accessing the
service from an unsecured HTTP port 80 to a secured channel on port 443. The purpose of
Nginx software is also to serve as a reverse-proxy for request handling, from entering the
service using the secure channel to processing into Spring boot application and server. If
necessary, Spring boot application distributes the request to other services. After
processing is complete, Spring boot returns the response to Nginx and Nginx serves the
response to the client.
Figure 4.7 - Global Architectural design
67
4.5 General development tools
For the purpose of server-side development, we have used an Integrated Development
Environment (IDE) called IntelliJ IDEA Ultimate edition, with version 2016.3.4. Android
Studio version number v2.3.0was used for development for the Android platform . Source
code control and revisions were achieved using a distributed version control system
called Git. The source code was hosted by a service called Bitbucket.
4.6 Technologies and frameworks used
In this section we will provide implementation details based on application
implementation.
4.6.1 Apache Maven
Apache Maven is a build automation tool that addresses two main concepts of software
developing
1. How software is compiled and built;
2. Defining external dependencies.
Maven uses XML format files called Project Object Model (POM), seen in Figure 4.8, in
which you describe the project structure, dependencies and project build plan. Maven
downloads external dependencies dynamically and stores them in the local cache. During
the compile and build cycle, it retrieves them from the local cache and builds the artifact
in a project build folder called »target«. Maven comes with a predefined build lifecycle
that is used as the order of goal execution. Every goal defines actions that correspond to
the building of the project.
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<!-- General build information -->
<modelVersion>4.0.0</modelVersion>
<groupId>pt.isep.sample</groupId>
<artifactId>artifactNameDefinition</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<!-- external dependencies -->
<dependencies>
68
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Figure 4.8 - Maven Project Object Model (POM) example
4.6.2 Spring framework and Spring boot
Spring is a Java application framework that, in its core, supports »inversion of control
(IOC) « of a Java container. Spring Framework is considered mostly as an alternative to
standard Java Enterprise Edition (»JavaEE«). It was initially developed by Rod Johnson.
Spring framework made a first public appearance in a publication of the book »Expert
One-on-One J2EE Design and Development« in October, 2002. Today, Spring is managed
by a team of developers at a company called Pivotal Software. The framework now has
many subprojects that enable developers easier integration and modular design of web
applications. As of 1 March, 2017, the last stable version of the project is 4.3.7 [45].
Spring boot
Spring boot is a subproject of Spring framework. Its primary focus is convention over
configuration which is defined as a software design paradigm that attempts to decrease
the number of decisions that a developer is initially required to make without losing
frameworks` flexibility. Spring boot enables packing a web application and application
server into a single unit called Java Archive (JAR) [46]. The developer can run both the
server and application using a single command for execution of Java programs.
Because of the modular architectural design of the application server, the Spring build
plugin checks the web project code, and packs into the JAR only the things that the web
application requires to run. More specifically, if the application is using socket technology
the Spring build plugin will package everything needed for an application server to
support its execution. That enables application servers and web application to exist as a
single unit and have as little memory footprint as possible. It also manages to provide
69
quicker jumpstart of the server and application, which helps when load balancing is
required. As of 10.5.2017, the latest stable version of Project Spring Boot is 1.5.3 [46].
Spring data
Spring data is a subproject that provides a consistent Spring programming model for
accessing the underlying data storage technologies. Its aim is to provide easier access to
relational, as well as non-relational databases, map-reduce frameworks and cloud-based
data services. Spring data is divided into two modules – the main module that is
developed by the company itself and community-driven modules [47].
4.6.3 Nginx
NGINX is a free, open-source web server created by Igor Sysoev in 2004 that can be used
as a reverse-proxy, load balancer and HTTP Cache. Nginx works by using an event-driven
asynchronous architecture which enables high performance and small memory footprint
[34]. Nginx can be used on operating systems such as Unix, Linux, BSD, MacOS, Solaris
and Windows [35].
In our application, we will be using Nginx as a reverse-proxy, subdomain translation and
client redirection software.
4.6.4 Ensuring encrypted communication
For ensuring encrypted communication by using TLS/SSL, we are going to use a project
called Let's Encrypt. Let's Encrypt is a CA that was launched on April 12, 2016 [35]. The
main objective of the Let's encrypt project is to make it more understandable and
intuitive to set up an HTTPS server and have a browser-trusted certificate without the
need of human intervention.
One of the steps for obtaining a CA trusted certificate without Let's encrypt is proving
who you are. CA have special teams to whom you must provide personal and business
details in order to obtain a valid CA-signed certificate. Project Let's encrypt simplifies this
by running a certificate management agent on the web-server itself [35].
70
4.6.5 Amazon Web Services
Amazon Web Services, or AWS for short, is a cloud service platform offered by a company
called Amazon. AWS offers on-demand cloud computing virtual private servers that are
easy to manage and scale [48]. AWS now has more than 70 available services that include
cloud platforms for software computation areas like:
1. Computing;
2. Storage;
3. Networking;
4. Database;
5. Analytics;
6. Application services;
7. Deployment management;
8. Mobile;
9. Developer tools.
Amazon EC2 cloud instances
Amazon EC2 cloud instance is a virtual server that is running in the Amazon AWS
ecosystem. Virtual servers are separated by purpose into several categories, that include:
1. General Purpose virtual servers;
2. Compute Optimised virtual servers;
3. Memory Optimised virtual server;
4. Accelerated Computing Instances virtual servers;
5. Storage Optimised virtual servers.
For the implementation of our project, we will use a general purpose virtual server with
T1. micro specification that includes [49]:
1. 1 Virtual CPU;
2. 1 GB of memory;
3. 30 GB of storage.
71
Amazon SES (Simple Email Service)
Amazon SES is a cloud based email service that enables sending and receiving email on a
scalable Amazon infrastructure. We have decided to use Amazon SES as the service for
sending verification emails [51]. Communication form details can be found in Figure 4.7.
Amazon ElasticSearch Service
Amazon ElasticSearch Service (AES) is an on demand cloud platform that enables
analytics, full text search and application monitoring [52]. We are using AES for the
purpose of full text search capabilities.
4.7 Application implementation details
Our application was built using the Java programming language Enterprise Edition using
the Spring Boot Framework, which enabled us to package application and server into a
single unit called Java Archive (JAR). Dependency management and code construction
was handled using Apache Maven. For testing purposes, we have used JUnit and
Arquillian software. JWT token handling was covered by using the framework JJWT (Java
JWT). Framework JJWT.
Java Json Web Token (»JJWT«) is an open source Java implementation based on the
following RFC specifications:
1. Json Web Tokens (JWT);
2. Json Web Signature (JWS);
3. Json Web Key (JWK);
4. Json Web Algorithms (JWA).
JJWT was developed initially by Les Hazelwood, the Chief Technology Officer (CTO) at a
company called Stormpath, and is now maintained by a group of community contributors.
JJWT stands as an open source library that can be used as an external dependency of any
Java project. It offers a simple and clean API to issue, sign and verify JWT tokens [24].
Three-tier application has been used for general application architectural structure. The
decision for three-tier application architecture was implemented because we wanted to
have a separation of concern. As seen in Figure 4.9, a presentation layer is implemented
that handles incoming and outgoing REST responses: A business logic layer that is
72
responsible for logical validation and processing. Furthermore, the data repository layer
was introduced for data handling, storing and mapping. For token processing and
resource protection, the interceptor layer was introduced to pre-handle incoming
requests for valid tokens on protected resources.
Figure 4.9 - Three tier architecture with interceptor
4.7.1 Security configuration
Spring Security is responsible for defining protected resources and listing unprotected
endpoints. Unprotected resources are endpoints that are intended for user
authentication and token reissuing. Unprotected resources do not require the use of
tokens. Security preferences are configured in the implementation using convenient
Spring Java annotations. Spring Security is responsible for defining protected resources
and listing unprotected endpoints.
@Configuration
public class SecurityConfig
extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable();
http.sessionManagement()
.sessionCreationPolicy
(SessionCreationPolicy.STATELESS);
}
}
73
Unprotected resources are endpoints that are intended for user authentication and token
reissuing. Unprotected resources do not require the use of tokens. Security preferences
are configured in the implementation using convenient Spring Java annotations. Spring
Security offers security configuration through the code or structured data files like XML,
YAML, or by a simple property file using the key-value approach. Security configuration
using annotations can be seen using the Figure Source code 1. Using the code, we disable
session management and enforce a stateless session creation policy. In order to define
interceptors, which serve as request filters, another configuration has to be provided. As
seen in Source code 2 with the initial start-up of the server and application, the
interceptor will be registered to the path patterns provided. We can also exclude some of
the paths by providing excluded path patterns. These paths will not be protected.
4.7.2 Client Domain and Server Subdomain Resolving
Communication flow in Figure 4.10 explains the Domain Name System (DNS) resolving in
order for a client to issue a request to the Server. DNS records are stored in a service
called namecheap.com.
@Bean
public AuthFilter authFilterInterceptor() {
return new AuthFilter();
}
@Override
public void configureDefaultServletHandling(
DefaultServletHandlerConfigurer configurer) {
configurer.enable();
}
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(authFilterInterceptor())
.addPathPatterns("/**")
.excludePathPatterns("/<excluded path pattern>")
}
Source code 2 - Interceptor registry configuration
Source code 1 – Security policy configuration
74
Figure 4.10 - DNS Address resolving
Once a client receives the direct IP address, the communication flow instructs the
establishment of a secure channel using TLS. TLS was explained in detail in subsection
3.1.8. Domain maestroamadeus.com is translated into the static IP 52.43.210.4. This is
the public IP that addresses the API gateway for our Amazon EC2 cloud instance. The first
one to process the request in line is an asynchronous subdomain server called Nginx. If a
client has made the request using an unsecured channel and port 80, Nginx is responsible
for client redirection on a secured channel - port 443. Nginx is also responsible to serve as
a reverse-proxy, as seen in Figure 4.11 - Request retransmission, which means it has to
transmit the client request from subdomain translation to the Spring boot application
server for processing.
Figure 4.11 - Request retransmission
4.7.3 Ensuring Secure communication
The project Let’s encrypt has been used for ensuring secure communication. If a client by
any chance makes an unsecured request, it is redirect to a secure channel. The TLS and
SSL certificate was obtained by using Let’s encrypt Certificate Manager. Every certificate is
valid for three months, then it needs to be reissued [35].
The renewal of a certificate is automated by using a timer execution, defined as cron job.
75
4.7.4 Obtaining Access and Refresh JWT tokens
The user can obtain an access and refresh token either by registering for our service or
logging in by providing his credentials. User registration and authentication is an
unprotected resource, so the client does not need to provide a JWT token for accessing
the URI endpoint. As seen in Figure 4.12, UserRestEndpoint controller class is
responsible for technical validation of a user request. Technical validation is checking the
user request for null or empty values. If validation succeeded, the user credentials are
submitted to the UserManagment Service Bean. In the
UserManagementServiceBean, user credentials are compared to the stored
information. If validation is successful, UserManagementBean calls JwtManager for
issuing first, an access token, and then a refresh token. Response with HTTP status code
200 OK is returned to the user with user information and compact refresh and access
tokens.
Figure 4.12 - Obtaining access and refresh tokens
76
4.7.5 Token Extraction and Token Validation Check
As seen in Figure 4.13 - Token validation, every request made to the protected resource
is intercepted by an authentication filter. The authentication filter intercepts the request
and extracts the authorisation header parameter. If the authorisation header parameter
is not present, the request is rejected automatically with the HTTP response code 403 -
Forbidden. If the header is present and starts with the “Bearer” schema, the filter
proceeds with the extraction of the token. The token, represented as a String type, is then
forwarded to JWT Manager, which validates the token in the following steps:
1. Load the secret key from local storage
2. Parse token using the key
a. Validate issuer
b. Validate token type
c. Parse claims
Figure 4.13 - Token validation
77
If the token is valid, the authentication filter proceeds with forwarding the request to the
REST controller, which processes the request and returns the result to the client. If the
token is invalid for any reason, the request is rejected. The client reacts on the rejected
response and uses a refresh token to obtain a new access token. If the refresh token is
also expired, the client shows to the user the login form. Source code 3 shows the
implementation of the procedure shown in Figure 4.13.
In the Source code 4 is shown the extraction and validation of the JWT token. The token
can either be:
1. Expired;
2. Unsupported;
3. Malformed;
4. Wrongly signed;
The JWT token is expired when the value of a reserved claim, represented as parameter
exp in the header of the token, is before the current time of the server. The token is
unsupported if the custom claims are not expected, the issuer is not correct, or the token
type is not correct. UnsupportedException indicates that a JWT was not constructed
correctly and should be rejected. Signature exception indicates that either calculating a
signature or verifying an existing signature of a JWT failed.
try {
JwtFidemToken jwtFidemToken = new JwtFidemToken();
jwtFidemToken.setCompactToken(accessToken);
jwtManager.validateJwtToken(jwtFidemToken,JwtType.ACCES_TOKEN);
LOG.debug("Authentication passed");
return true;
} catch (ExpiredJwtException expired) {
final String message = expired.getMessage();
LOG.debug(message);
httpServletResponse.sendError(HttpServletResponse.SC_UNAUTHORISED);
} catch (Exception anyException) {
final String message = anyException.getMessage();
LOG.debug(message);
httpServletResponse.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERRO
R);
} // end try-catch
Source code 3 - Authentication filter
78
4.7.6 Client Google Drive integration
Google Drive integration is done on a client side – Android application. Google Drive
integration is need so that the musician can import sheet music from his Google Drive
folder. As seen in Figure 4.14, a musician can do so by clicking the addition button and,
from the dialogue, choose – »From local files«.
Figure 4.14 - Song addition dialogue
Source code 4 - JWT Manager token validation
/**
* Method validates JWT token
* @param userRequestJWTtoken token information
* @throws ExpiredJwtException expired token
* @throws UnsupportedJwtException unsupported JWT
* @throws MalformedJwtException Malformed JWT
* @throws SignatureException Incorrect key usage
*/
public void validateJwtToken(JwtFidemToken userRequestJWTtoken,
JwtType jwtType) throws
ExpiredJwtException,
UnsupportedJwtException,
MalformedJwtException,
SignatureException{
Key key = prepareJWTKey();
Jwts.parser()
.setSigningKey(key)
.requireIssuer("<ISSUER>")
.require("<TOKEN_TYPE>", "<ACCES_TOKEN>")
.parseClaimsJws(userRequestJWTtoken.getCompactToken());
} // validateJwtToken()
79
This brings the musician to another dialogue where he can choose Google Drive. This can
be seen in Figure 4.15.
Figure 4.15 - Google Drive integration
When the musician choses the pdf with sheet music it gets downloaded automatically
and transformed into a form that the application can read. The musician can open
transform the sheet music, which can be seen in Figure 4.16.
Figure 4.16 - Song addition and playing
80
4.8 Testing
Testing results and approaches will be presented and addressed in this section. The focus
will be put on testing the communication channel, response rate, performance, and
responsiveness of the API.
4.8.1 Testing Transport Layer Security
TLS testing score is determined by a number of varying factors. These factors include:
1. Certificate;
2. Protocol support;
3. Key exchange;
4. Cipher strength;
For testing these factors, we have used the tool ssllabs.com, that is an online tool made
by a company called Qualys SSL Labs. The tool analyses and tests the four factors
described, and tries to enforce weak protocols and unsecure algorithms during the
negotiation phase between server and client [68]. After concluding the test, a report is
provided with detailed explanation of what can be improved to ensure more secure
communication encryption. The report contains a graded score based on numerical
representation of tested factors. In Table 4.2 we present the numerical score and
associated grade.
Table 4.2 - Scoring table of SSL/TLS testing tool SSL Labs [68]
Numerical Score Grade
score >= 80 A
score >= 65 B
score >= 50 C
score >= 35 D
score >= 20 E
score < 20 F
For key generation we have used the software called OpenSSL, which enabled us the
generation of the 2048 bit Diffie-Hellman group.
81
As seen in Figure 4.17, rgw testing score for our API Gateway`s support of HTTPS was A+.
Figure 4.17 - TLS/SSL Testing score
4.8.2 Load Testing on secure and unsecure channels
In this section, we want to test the API response time with and without the usage of the
secure channel, and how much impact does the establishment of TLS bring. For the
execution of load testing, we have used a tool called Apache JMeter version 3.2. A test
plan has been created that sent 300 requests in the time span of 10 seconds (s) onto the
API gateway. More requests cannot be done because of the limitation of the client
performing the test. In Table 4.3, are the test results of testing the API without the usage
of the secure channel. Ten consecutive tests were executed.
Table 4.3 - Test result unsecure channel
Test execution Minimum response
time
(in milliseconds)
Maximum response
time
(in milliseconds)
Average
response time
(in milliseconds)
1 374 434 404
2 376 494 406
3 379 440 407
4 375 440 402
5 374 577 407
82
6 375 432 400
7 375 434 402
8 379 385 381
9 378 567 422
10 374 434 402
Calculation of average, minimum, maximum and Standard Deviation can be done based
on Table 4.3. This calculation is presented in Table 4.4.
Table 4.4 - Statistical overview of testing on an unsecure channel
Minimum response Maximum response Average response
Average 375,9ms 463,7ms 403,3ms
Min 374ms 385ms 381ms
Max 379ms 577ms 422ms
Standard
Deviation
2,024 62,711 9,989
The same tests were run again with the difference that this time we were using a secure
channel with SSL/TLS enabled. Results of testing are presented in Table 4.5
Table 4.5 - Testing results on a secure channel
Test execution Minimum response
time
(in milliseconds)
Maximum response
time
(in milliseconds)
Average
response time
(in milliseconds)
1 996 1147 1056
2 987 1140 1063
3 991 1184 1063
4 990 1144 1057
5 997 1138 1070
6 992 1193 1056
7 989 1152 1053
8 991 1150 1060
9 987 1139 1058
10 992 1131 1060
83
As seen in Table 4.5, enabling a secure channel extends the response time by
almostdouble.
New set of calculations of average, minimum, maximum and Standard Deviation can be
done based on Table 4.5. This calculation is presented in Table 4.6.
Table 4.6 - Statistical overview of secure channel results
Minimum
response time
Maximum response
time
Average response
time
Average 991,2ms 1151,8ms 1059,6ms
Min 987ms 1131ms 1053ms
Max 997ms 1193ms 1070ms
Standard
Deviation
3.326 20,405 4,835
We can now compare the statistical overview of Table 4.4 and Table 4.6.
Table 4.7 - Testing results comparison
Min Max Average
Unsecure channel 374ms 577ms 403,3ms
Secure channel 987ms 1193ms 1059,6ms
Difference 613ms 616ms 656,3ms
As seen in Figure 4.6, we can conclude that there is some performance trade-off when
using TLS/SSL. However, we do not gain so much performance optimization, given that
we have sent the token through the unsecured channel and now risk other security
vulnerabilities.
4.8.3 Testing the size impact of token on performance
The size of the token is important, because it is sent with every request to the server. We
will gradually increase the size of the token and test the response time execution. Initial
test size of a token is 0.2 KiloByte (KB). The test also consists of sending 300 requests in
the time span of 10 seconds into the server API and analysing the response time. The
84
secure channel will be enabled during testing. In Table 4.8 we have conducted five
consecutive tests on token size 0.2 KiloBytes.
Table 4.8 - Testing size impact first iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 1035ms 1205ms 1106ms
2 1033ms 1380ms 1148ms
3 1027ms 1226ms 1185ms
4 1044ms 1315ms 1210ms
5 1036ms 1322ms 1110ms
For the next testing iteration, we have increased the size of the token to 1KB and rerun
tests. The results of testing can be seen in Table 4.9.
Table 4.9 - Testing size impact second iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 1102ms 1205ms 1102ms
2 1058ms 1220ms 1105ms
3 1072ms 1326ms 1089ms
4 1022ms 1319ms 1205ms
5 1046ms 1289ms 1210ms
There was still no significant performance impact based on the size of token, so we
increased the size to 10KB and reran the tests. Results can be seen in Table 4.10.
Table 4.10 - Testing size impact third iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 1107ms 1361ms 1174ms
2 1103ms 1291ms 1109ms
3 1092ms 1335ms 1158ms
4 1205ms 1453ms 1314ms
5 1177ms 1289ms 1265ms
85
The result of increasing the size of the token further to the size of 20KB and rerunning the
test and results can be seen in Table 4.11.
Table 4.11 - Testing size impact fourth iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 1222ms 1457ms 1280ms
2 1140ms 1356ms 1301ms
3 1105ms 1280ms 1250ms
4 1190ms 1210ms 1220ms
5 1252ms 1389ms 1385ms
We still could not get conclusive results, so we re-increased the size of the token. In Table
4.12 are presented results of testing a 40KB size token.
Table 4.12 - Testing size impact fifth iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 1485ms 5581ms 3547ms
2 1874ms 4782ms 3788ms
3 2801ms 4941ms 2908ms
4 1785ms 6280ms 4852ms
5 3458ms 8425ms 6528ms
As seen in Table 4.12, the server started to respond very unpredictably. To test the
impact further we have increased the size to 80KB. Results can be seen in Table 4.13.
Table 4.13 - Testing size impact sixth iteration
Test execution Minimum response time Maximum response
time
Average
response time
1 4251ms 61785ms 34121ms
2 8425ms 54245ms 21425ms
3 21123ms 77312ms 44014ms
4 6547ms 64185ms 33412ms
86
5 14148ms 48418ms 25475ms
In order to complete the testing, the connection timeout had to be increased to 90
seconds. Even so, some requests were dropped, because the API could not return a
response in the given time. In Table 4.14 we can now present a statistical overview of the
results. Out of every 5 test executions, we extract the smallest minimum value, the
biggest maximum value, and calculate the median of average response times.
Table 4.14 - Token size impact on performance
Token size
(in kilobytes)
Minimum response
time (in milliseconds)
Maximum response time
(in milliseconds)
Average response
time (in
milliseconds)
0.2 KB 1027 1380 1148
1KB 1022 1326 1105
10KB 1092 1453 1174
20KB 1105 1457 1280
40KB 1485 8425 3788
80KB 4251 77312 33412
At first, as we gradually kept increasing the size of the token, there was no sign of
performance issues. But, as soon as we crossed the size of 20KB, the response time
escalated by a much bigger factor that we expected. To even achieve processing of an
80KB size header, some modifications of software configuration had to be done. From
changing the default header limit and the size of the application server, to changing the
Nginx reverse-proxy header limit size and increasing the timeout for the test requests.
Graphical representation of test results can be seen in Figure 4.18 - Line graph of token
impact on performance.
87
Figure 4.18 - Line graph of token impact on performance
4.8.4 Testing conclusions
In this section, we will provide a summary and conclusions that derive from the tests
executed in previous subsections 4.4.1, 4.4.2 and 4.4.3.
In subsection 4.4.1, we have executed the tests to check how strong our security for
ensuring secure communication is. Before executing the tests, we have assumed that our
communication security is not strong. By testing our TLS/SSL, have shown that our API
offers the verity of strong ciphers, and weak ciphers cannot be enforced by the client.
In subsection 4.4.2, our aim was to test how does the establishment of SSL/TLS impact on
the performance of requests and responses. We have assumed that the difference in
performance between secure and unsecured channels will be minimum or none.
However, with testing, we can conclude that the establishment of a secure channel brings
a performance penalty to every subsequent request. More specifically, our tests have
shown that between 200-300ms is added to every request due to secure channel
establishment. However, this result is still negligible, as the secure channel is an absolute
necessity to ensure integrity, identity, and encryption.
Testing the size impact of the token on the performance of API was done in subsection
4.4.3,. We assumed that the size of the token will affect the performance of serving
88
responses, since the token is sent with every request to the server. At first, as we
gradually increased the size of the token, the results were inconclusive. As soon as we
reached the size of 20KB, the impact was really shown. We can conclude that tokens are
not intended for transferring a large amount of data between two parties.
4.9 Summary
This concludes the chapter on implementation details, design and testing. As
implementation was concluded and architecture was set on the Amazon cloud platform,
we have tested the correct behaviour and stress tested the server under certain
conditions. The results of the tests have provided conclusions on the certain sub
questions and can now be answered.
89
5 CONCLUSION AND FUTURE WORK
With this chapter, we review the achievements that we accomplished during this
dissertation. Revisiting the problem, goals and proposed solutions described in chapter 2
we wanted to implement a solution that follows the fundamental principles of stateless
communication in REST, and addresses user authentication and authorisation using
security token implementation JWT and OAuth 2.0. Furthermore, we wanted to show the
importance of securing the transmission and communication flow by using underlying
HTTP security standards such as SSL and TLS. We have done so by implementing a
platform that helps musicians organise their sheet music with the use of the Android
application with provided background service. Background service was implemented by
addressing the fundamental development problems we face today, and uses JWT and
OAuth 2.0 for user authentication and authorisation. These technical problems were
addressed in subsection 2.2, and by doing so, we have analysed the problems from the
technical and theoretical perspectives, implemented and tested what is needed in order
to achieve a viable and working solution.
SQ 1. How does implementing and usage of TLS/SSL impact the performance of the
REST endpoint?
As seen in subsection 4.6.1, servers` TLS configurations have a very high grade of security,
which brings a certain performance penalty when HTTPS is enabled. As seen in subsection
4.6.2, there was between a 200-300ms per request performance impact when TLS was
used for securing the communication. This performance impact is due to the
computational cost required for establishing and negotiating about the secure channel
parameters. Even though securing a communication channel brings some performance
impacts, security should never be disabled for reasons of performance and
responsiveness.
SQ 2. How does the implementation of token security and size of the token impact the
performance of the communication flow?
HTTP as a protocol does not prescribe the size limit of request header parameters.
However, many applications have a request limit built into the configuration. In order to
test the size impact on the performance of requests and responses, we had to
90
reconfigure the Nginx reverse-proxy, as well as the application server parameters. At first,
as we gradually increased the size of the token, we did not see any significant
performance impacts. However, when the size went above 20KB, the test results changed
dramatically. The average response was at first increased by double, and then even by
10x the previous factor. The conclusion we can make is that if you have to put a large
amount of data into a security token ,you have to revise the decision, and either make
structural changes or discard the use of token concepts altogether.
SQ 3. Does implementing custom JWT token security authentication or implementation
of OAuth 2.0 cause higher complexity of code?
Yes. Since handling the restricted access is no longer delegated to the application server,
the security implementation has to be done by the developer. When implementing
authentication and authorisation using JWT or OAuth 2.0, developers have to create a
custom solution for API security. In solutions that use JWT, we have to implement
everything from token issuing, refreshing and revoking. This can bring a lot of complexity
to the solution itself, since the requests need to be intercepted, validated and forwarded.
When using OAuth 2.0, the responsibility for user and token management is delegated to
third-party applications. This means that the application is tightly coupled with the third-
party application and that integration has to be supported.
SQ 4. Does the usage of the Secured Hypertext Transfer Protocol (HTTPS) ensure secure
transfer of token from client to server?
A secure channel is established before the first byte of communication between client
and server is sent. A Man In The Middle attack is possible if unencrypted data is sent and
a malicious attacker intercepts the requests sent from a client or response sent from a
server. This can be prevented if the channel is encrypted. However, the server has to
support strong ciphers and encryption algorithms. It is necessary to ensure that a strong
encryption is used to encrypt the communication channel, because using an obsolete
encryption algorithm can inflict security vulnerabilities, since weak encryption algorithms
can be broken easily. Further testing of ensuring a strong encryption algorithm on our
Web Service will be addressed in section 4.8.1. However, this dissertation will not cover
the attacks on encryption algorithms.
91
Main Question:
Does the implementation of a solution that follows the fundamental principles of
stateless communication in REST and addresses user authentication and authorisation
using security token implementation JWT and OAuth 2.0, provide a higher level of
scalability and security?
Yes. Tokens force developers to implement a solution that does not keep any application
state, but rather transfers it to the client. Keeping no state means that no additional
resources are needed to store application state data on the server side. This makes cloud
and server instance much easier to scale, since there is no need for shared context.
Security, however, must be considered from multiple perspectives: From the
communication perspective, by ensuring encrypted transmission, to the encoded,
encrypted and signed tokens. Since tokens are, technically speaking, a really young
concept, there will probably still be some changes in the upcoming years to the proposed
Standards and implementations.
5.1 Future work
During this dissertation, we have implemented a viable prototype of an Android
application that focuses on the domain of helping musicians organise. In the future work,
we would like to upgrade our product by enabling pairing the mobile application with a
Bluetooth pedal, which will enable hands-free turning of the pages during playing.
Furthermore, we would like to expand our project on different mobile platforms, such as
Apple iOS, and advance slowly into the market by offering our application to musicians
and Music Schools.
92
5.2 Summary
During this dissertation, we have provided implementation details, architectural design,
diagrams and testing, that helped us understand better what problems of user
authentication and authorisation we are facing today when we want to develop
applications that serve data to multiple, technology independent, clients. When using
token authentication and authorisation models, we must consider the advantages and
drawbacks that we will face during the development, and go from there. Not every
solution needs to implement a token-based authentication and authorisation, and it is a
developer`s own decision what approach to use.
93
6 BIBLIOGRAPHY
[1] David Sprott and Lawrence Wilkes. (2004, Januar) Understanding Service-Oriented
Architecture. [Online]. HYPERLINK "https://msdn.microsoft.com/en-
us/library/aa480021.aspx"
https://msdn.microsoft.com/en-us/library/aa480021.aspx
(visited on 03/21/2017).
[2] André B Bondi, "Characteristics of scalability and their impact on performance.," ,
2000.
[3] Google INC. (2017, Apr.) Platform Versions. [Online]. HYPERLINK
"https://developer.android.com/about/dashboards/index.html" \l "Platform"
https://developer.android.com/about/dashboards/index.html#Platform
(visited on 03/24/2017).
[4] World Wide Web Consortium. (2004, Feb.) Web Services Glossary. [Online].
HYPERLINK
"https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/" \l "webservice"
https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice
(visited on 03/25/2017).
[5] (2004, July) "Exclusive.NET Developer's Journal "Indigo" Interview with Microsoft's
Don Box". [Online]. HYPERLINK "http://dotnet.sys-con.com/node/45908"
http://dotnet.sys-con.com/node/45908
(visited on 03/26/2017).
[6] (2015) Overview of Orpheus App. [Online]. HYPERLINK "https://orpheus-app.com/"
https://orpheus-app.com/
(visited on 03/26/2017).
[7] Zubersoft. (2011) About / Features. [Online]. HYPERLINK
"http://www.zubersoft.com/mobilesheets/about.html"
http://www.zubersoft.com/mobilesheets/about.html
(visited on 03/26/2017).
[8] musescore.org. (2002, September ) musescore.org. [Online]. HYPERLINK
"https://musescore.org/en" https://musescore.org/en
94
(visited on 03/28/2017).
[9] Roy Thoma Fielding, Architectural Styles and the Design of Network-based Software
Architectures.: University of California, Irvine, 2000.
(visited on 03/29/2017).
[10] Google Inc. Explore. [Online]. HYPERLINK
"https://trends.google.com/trends/explore"
https://trends.google.com/trends/explore
(visited on 04/01/2017).
[11] Barbara Fox, Satoshi Hada, Brian LaMacchia, Hiroshi Maruyama Allen Brown. (2001,
Feb.) SOAP Security Extensions: Digital Signature. [Online]. HYPERLINK
"https://www.w3.org/TR/SOAP-dsig/"
https://www.w3.org/TR/SOAP-dsig/
(visited on 04/01/2017).
[12] Google Inc. (2017, Apr.) Dashoard. [Online]. HYPERLINK
https://developer.android.com/about/dashboards/index.html
https://developer.android.com/about/dashboards/index.html
(visited on 04/01/2017).
[13] Google Inc. (2015) Android 6.0 Marshmallow. [Online]. HYPERLINK
"https://developer.android.com/about/versions/marshmallow/index.html"
https://developer.android.com/about/versions/marshmallow/index.html
(visited on 04/01/2017).
[14] RSA SecurID. Security tokens for identity and access management. [Online].
HYPERLINK
"https://www.rsa.com/en-us/products/rsa-securid-suite/securid-hardware-tokens"
https://www.rsa.com/en-us/products/rsa-securid-suite/securid-hardware-tokens
(visited on 04/03/2017).
[15] Yubico. Yubico for Developers - yubikey documentation. [Online]. HYPERLINK
"https://developers.yubico.com/"
https://developers.yubico.com/
(visited on 04/03/2017).
[16] Apache foundation. (2005, July) maven.apache.org. [Online]. HYPERLINK
95
"https://maven.apache.org/what-is-maven.html"
https://maven.apache.org/what-is-maven.html
(visited on 04/04/2017).
[17] Apache foundation inc. Introduction to the Maven Build Lifecycle. [Online].
HYPERLINK "https://maven.apache.org/guides/introduction/introduction-to-the-
lifecycle.html"
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
(visited on 04/06/2017).
[18] MuseScore product description. [Online]. HYPERLINK
"https://musescore.org/en/handbook/musescore-product-description"
https://musescore.org/en/handbook/musescore-product-description
(visited on 04/15/2017).
[19] BauM Software. SongBook +. [Online]. HYPERLINK
"https://itunes.apple.com/us/app/songbook/id447755419?mt=8"
https://itunes.apple.com/us/app/songbook/id447755419?mt=8
(visited on 04/15/2017).
[20] Amazon. Amazon Cognito. [Online]. HYPERLINK
"https://aws.amazon.com/cognito/"
https://aws.amazon.com/cognito/
(visited on 04/18/2017).
[21] Okta Headquarters. okta.com. [Online]. HYPERLINK
"https://www.okta.com/solutions/" \l "Identity"
https://www.okta.com/solutions/#Identity
(visited on 05/18/2017).
[22] Apache foundation. API documentation. [Online]. HYPERLINK
"https://oltu.apache.org/"
https://oltu.apache.org/
(visited on 04/20/2017).
[23] Pivotal Software. Spring Security - documentation. [Online]. HYPERLINK
"https://projects.spring.io/spring-security/"
https://projects.spring.io/spring-security/
96
(visited on 06/18/2017)
[24] Stormpath. JJWT – JSON Web Token for Java and Android. [Online]. HYPERLINK
"https://stormpath.com/blog/jjwt-how-it-works-why"
https://stormpath.com/blog/jjwt-how-it-works-why
(visited on 05/10/2017).
[25] Auth0. HapiJS Authentication - Secure Your API With JWT. [Online]. HYPERLINK
"https://auth0.com/blog/hapijs-authentication-secure-your-api-with-json-web-
tokens/"
https://auth0.com/blog/hapijs-authentication-secure-your-api-with-json-web-
tokens/
(visited on 05/08/2017).
[26] Unknown author. [Online]. HYPERLINK
"https://godoc.org/github.com/dgrijalva/jwt-go"
https://godoc.org/github.com/dgrijalva/jwt-go
(visited on 05/08/2017).
[27] IBM inc. OAuth 2.0. [Online]. HYPERLINK
"https://www.ibm.com/developerworks/library/se-oauthjavapt3/image002.png"
https://www.ibm.com/developerworks/library/se-oauthjavapt3/image002.png
(visited on 05/24/2017).
[28] MacRoumors.com. What's New in iOS 10. [Online]. HYPERLINK
"https://www.macrumors.com/roundup/ios-10/"
https://www.macrumors.com/roundup/ios-10/
(visited on 05/13/2017).
[29] David Smiths. iOS Version Stats. [Online]. HYPERLINK "https://david-
smith.org/iosversionstats/"
https://david-smith.org/iosversionstats/
[30] Auth0. JWT introduction. [Online]. HYPERLINK "https://jwt.io/introduction/"
https://jwt.io/introduction/
(visited on 05/14/2017).
[31] connect2id.com. How to generate a JSON Web Key. [Online]. HYPERLINK
"https://connect2id.com/products/nimbus-jose-jwt/examples/jwk-generation"
97
https://connect2id.com/products/nimbus-jose-jwt/examples/jwk-generation
(visited on 05/22/2017).
[32] Prabath Siriwardena. JWT, JWS and JWE for Not So Dummies! [Online]. HYPERLINK
"https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-
b63310d201a3"
https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-
b63310d201a3
(visited on 05/23/2017).
[33] Auth0. OAuth 2.0. [Online]. HYPERLINK
"https://auth0.com/docs/protocols/oauth2"
https://auth0.com/docs/protocols/oauth2
(visited on 05/26/2017).
[34] Nginx, Inc. NGINX Wiki. [Online]. HYPERLINK
"https://www.nginx.com/resources/wiki/"
https://www.nginx.com/resources/wiki/ (visited on 06/15/2017).
[35] Nginx inc. Tested OS and platform. [Online]. HYPERLINK "http://nginx.org/en/" \l
"tested_os_and_platforms"
http://nginx.org/en/#tested_os_and_platforms
(visited on 06/16/2017).
[36] Internet Security Research Group (ISRG). https://letsencrypt.org. [Online].
HYPERLINK "https://letsencrypt.org/docs/"
https://letsencrypt.org/docs/
(visited on 06/17/2017).
[37] Internet Security Research Group (ISRG). letsencrypt.org. [Online]. HYPERLINK
"https://letsencrypt.org/images/le-logo-standard.png"
https://letsencrypt.org/images/le-logo-standard.png
(visited on 06/16/2017).
[38] Microsoft, J. Bradley, Ping Identity, N. Sakimura, NRI M. Jones. (2015, May) Internet
Engineering Task Force (IETF), Request for Comments: 7519. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc7519"
https://tools.ietf.org/html/rfc7519 (visited on 06/19/2017).
98
[39] Auth0 INC. Introduction to JSON Web Tokens. [Online]. HYPERLINK
"https://jwt.io/introduction/"
https://jwt.io/introduction/
(visited on 05/15/2017).
[40] Microsoft, J. Hildebrand, Cisco M. Jones. (2015, May) JSON Web Encryption (JWE),
Internet Engineering Task Force (IETF), Request for Comments: 7516. [Online].
HYPERLINK "https://tools.ietf.org/html/rfc7516"
https://tools.ietf.org/html/rfc7516
(visited on 06/16/2017).
[41] Microsoft M. Jones. (2015, May) JSON Web Key (JWK), Internet Engineering Task
Force (IETF), Request for Comments: 7517. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc7517
[42] Microsoft M. Jones. (2015, May) JSON Web Algorithms (JWA), Internet Engineering
Task Force (IETF), Request for Comments: 7518. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc7518"
https://tools.ietf.org/html/rfc7518 /
(visited on 06/17/2017).
[43] Microsoft, J. Bradley, Ping Identity, N. Sakimura, NRI M. Jones. (2015, May) JSON
Web Signature (JWS), Internet Engineering Task Force (IETF), Request for Comments:
7515. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc7515"
https://tools.ietf.org/html/rfc7515
(visited on 06/22/2017).
[44] Tim Mclean. (2015, March) Critical vulnerabilities in JSON Web Token libraries.
[Online]. HYPERLINK "https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-
confusion.html"
https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html /
(visited on 05/22/2017).
[45] Apache Foundation Inc. (2017, June) What is Maven? [Online]. HYPERLINK
"https://maven.apache.org/what-is-maven.html"
https://maven.apache.org/what-is-maven.html
(visited on 06/18/2017).
99
[46] Pivotal Inc. Spring Framework. [Online]. HYPERLINK
"https://projects.spring.io/spring-framework/"
https://projects.spring.io/spring-framework/
(visited on 06/18/2017).
[47] Pivotal Inc. Reference documentation. [Online]. HYPERLINK "https://spring.io/docs"
https://spring.io/docs
(visited on 06/22/2017).
[48] Pivotal Inc. (2017, May) Spring boot. [Online]. HYPERLINK
"https://projects.spring.io/spring-boot/"
https://projects.spring.io/spring-boot/
(visited on 06/25/2017).
[49] Pivotal Software, Inc. (2017, May) Spring Data. [Online]. HYPERLINK
"http://projects.spring.io/spring-data/"
http://projects.spring.io/spring-data/
(visited on 06/26/2017).
[50] Amazon. Amazon Web Services. [Online]. HYPERLINK "https://aws.amazon.com/"
https://aws.amazon.com/
(visited on 06/23/2017).
[51] Amazon Inc. Amazon EC2. [Online]. HYPERLINK "https://aws.amazon.com/ec2/"
https://aws.amazon.com/ec2/
(visited on 06/26/2017).
[52] Amazon Inc. Amazon Elasticsearch Service. [Online]. HYPERLINK
"https://aws.amazon.com/elasticsearch-service/"
https://aws.amazon.com/elasticsearch-service/
(visited on 06/26/2017).
[53] Tony Mauro. (2015, February) Adopting Microservices at Netflix: Lessons for
Architectural Design. [Online]. HYPERLINK
"https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/"
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
(visited on 06/28/2017).
[54] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF).
100
[Online]. HYPERLINK "https://tools.ietf.org/html/rfc6749"
https://tools.ietf.org/html/rfc6749
(visited on 05/28/2017).
[55] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF) -
section-1.3. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc6749"
https://tools.ietf.org/html/rfc6749
(visited on 06/01/2017).
[56] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF) -
section-4; Obtaining Authorization. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc6749"
https://tools.ietf.org/html/rfc6749
(visited on 05/27/2017).
[57] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF) -
Authorization Code Grant. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc6749" \l "section-4.1"
https://tools.ietf.org/html/rfc6749#section-4.1
(visited on 05/28/2017).
[58] http://jlabusch.github.io/oauth2-server/. OAUTH 2.0 SERVER. [Online]. HYPERLINK
"http://jlabusch.github.io/oauth2-server/"
http://jlabusch.github.io/oauth2-server/
(visited on 06/14/2017).
[59] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF) -
OAuth 2.0 - client types. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc6749"
\l "section-2.1"
https://tools.ietf.org/html/rfc6749#section-2.1
(visited on 06/14/2017).
[60] Ed., Microsoft D. Hardt. (2012, October) Internet Engineering Task Force (IETF) -
Client authentication. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc6749" \l
"section-3.2.1"
https://tools.ietf.org/html/rfc6749#section-3.2.1
(visited on 06/15/2017).
101
[61] Apple inc. IOS10. [Online]. HYPERLINK "https://www.apple.com/ios/ios-10/"
https://www.apple.com/ios/ios-10/
[62] Roy Thomas Fielding. (2000) Architectural Styles and the Design of Network-based
Software Architectures. Ph.D. Dissertation. [Online]. HYPERLINK
"https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm"
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
(visited on 05/14/2017).
[63] UC Irvine, J. Gettys, Compaq/W3C, J. Mogul, Compaq, H. Frystyk, W3C/MIT, L.
Masinter, Xerox, P. Leach, Microsoft, T. Berners-Lee, W3C/MIT R. Fielding. (1999)
Network Working Group. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc2616"
\l "section-13"
https://tools.ietf.org/html/rfc2616#section-13
(visited on 05/16/2017).
[64] IBM Inc. (2017, June) An overview of the SSL or TLS handshake. [Online]. HYPERLINK
"https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.sec
.doc/q009930_.htm"
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.sec.
doc/q009930_.htm
(visited on 06/14/2017).
[65] Independent, E. Rescorla, RTFM, Inc. T. Dierks. (2008, August) Network Working
Group - The Transport Layer Security (TLS) Protocol. [Online]. HYPERLINK
"https://tools.ietf.org/html/rfc5246"
https://tools.ietf.org/html/rfc5246
(visited on 04/14/2017).
[66] Independent, E. Rescorla, RTFM, Inc. T. Dierks. (2008, August) Network Working
Group - The Transport Layer Security (TLS) Protocol - Handshake Protocol Overview.
[Online]. HYPERLINK "https://tools.ietf.org/html/rfc5246" \l "section-7.3"
https://tools.ietf.org/html/rfc5246#section-7.3
(visited on 06/16/2017).
[67] Nginx Inc. Adopting Microservices at Netflix: Lessons for Architectural Design.
[Online]. HYPERLINK
102
"https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/"
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
(visited on 06/22/2017).
[68] Qualys Inc. SSL Server Rating Guide. [Online]. HYPERLINK
"https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide#what-this-guide-
does-not-cover"
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide (visited on
06/29/2017).
[69] Digital certificates [Online]. HYPERLINK
"http://searchsecurity.techtarget.com/definition/digital-certificate"
http://searchsecurity.techtarget.com/definition/digital-certificate
(visited on 09/26/2017).
[70] Magnetic Tape Storage [Online]. HYPERLINK "http://www-
03.ibm.com/ibm/history/ibm100/us/en/icons/tapestorage/"
http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/tapestorage/
(visited on 09/26/2017)
[71] What is RFID? [Online]. HYPERLINK
"http://www.technovelgy.com/ct/technology-article.asp"
http://www.technovelgy.com/ct/technology-article.asp
(visited on 09/26/2017).
[72] Biometrics [Online]. HYPERLINK
"https://www.computerhope.com/jargon/b/biometri.htm"
https://www.computerhope.com/jargon/b/biometri.htm
(visited on 09/26/2017).
[73] How does the magnetic strip of credit cards work? [Online]. HYPERLINK
"https://www.quora.com/How-does-the-magnetic-strip-of-credit-cards-work-Whats-
the-science-behind-that"
https://www.quora.com/How-does-the-magnetic-strip-of-credit-cards-work-Whats-
the-science-behind-that
(visited on 09/27/2017).
[74] Using RFID. [Online]. HYPERLINK
103
"https://smartphones.gadgethacks.com/how-to/tap-card-dissolved-use-acetone-
transfer-rfid-tag-your-phone-0138161/"
https://smartphones.gadgethacks.com/how-to/tap-card-dissolved-use-acetone-
transfer-rfid-tag-your-phone-0138161/
(visited on 09/27/2017).
[75] Biometric devices. [Online]. HYPERLINK
"https://www.indiamart.com/proddetail/biometric-devices-12896938788.html"
https://www.indiamart.com/proddetail/biometric-devices-12896938788.html
(visited on 09/27/2017).
[76] Chapter 4. Kerberos. [Online] HYPERLINK
"https://www.safaribooksonline.com/library/view/hadoop-
security/9781491900970/ch04.html
(visited on 01/08/201)