Comparison of JWT and OAuth 2.0 authorisation and … · 2020-01-30 · Primerjava tehnik JWT in oAuth 2.0 za avtorizacijo in avtentikacijo pri uporabi storitev REST Ključne besede:

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

../../../../../../../Downloads/MAG_Vid_Visočnik_feri_final.doc#_Toc507350148




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


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


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);


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



<modelVersion>4.0.0</modelVersion>

<groupId>pt.isep.sample</groupId>

<artifactId>artifactNameDefinition</artifactId>

<packaging>jar</packaging>

<version>1.0-SNAPSHOT</version>



<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);


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


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


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


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


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


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

https://msdn.microsoft.com/en-us/library/aa480021.aspx

https://developer.android.com/about/dashboards/index.html#Platform

https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice

http://dotnet.sys-con.com/node/45908

https://orpheus-app.com/

http://www.zubersoft.com/mobilesheets/about.html

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


(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

https://trends.google.com/trends/explore

https://www.w3.org/TR/SOAP-dsig/



https://developer.android.com/about/versions/marshmallow/index.html

https://www.rsa.com/en-us/products/rsa-securid-suite/securid-hardware-tokens

https://developers.yubico.com/

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/


https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

https://musescore.org/en/handbook/musescore-product-description

https://itunes.apple.com/us/app/songbook/id447755419?mt=8

https://oltu.apache.org/

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"

https://stormpath.com/blog/jjwt-how-it-works-why

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/

https://www.macrumors.com/roundup/ios-10/


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

https://connect2id.com/products/nimbus-jose-jwt/examples/jwk-generation

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

https://auth0.com/docs/protocols/oauth2

http://nginx.org/en/#tested_os_and_platforms

https://letsencrypt.org/docs/

https://letsencrypt.org/images/le-logo-standard.png

98

[39] Auth0 INC. Introduction to JSON Web Tokens. [Online]. HYPERLINK

"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 /

(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"


(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"


(visited on 06/18/2017).



https://tools.ietf.org/html/rfc7518%20/

https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-confusion.html%20/


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

https://projects.spring.io/spring-framework/

https://spring.io/docs

https://projects.spring.io/spring-boot/

100

[Online]. HYPERLINK "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"


(visited on 06/01/2017).


section-4; Obtaining Authorization. [Online]. HYPERLINK



(visited on 05/27/2017).


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


OAuth 2.0 - client types. [Online]. HYPERLINK "https://tools.ietf.org/html/rfc6749"

\l "section-2.1"


(visited on 06/14/2017).


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





http://jlabusch.github.io/oauth2-server/


https://tools.ietf.org/html/rfc6749#section-3.2.1

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



(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"


(visited on 06/16/2017).

[67] Nginx Inc. Adopting Microservices at Netflix: Lessons for Architectural Design.

[Online]. HYPERLINK

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

https://tools.ietf.org/html/rfc2616#section-13

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



102

"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


http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/tapestorage/

http://www.technovelgy.com/ct/technology-article.asp

https://www.computerhope.com/jargon/b/biometri.htm

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

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)

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/

https://www.indiamart.com/proddetail/biometric-devices-12896938788.html

Documents

Comparison of JWT and OAuth 2.0 authorisation and … · 2020-01-30 · Primerjava tehnik JWT in oAuth 2.0 za avtorizacijo in avtentikacijo pri uporabi storitev REST Ključne besede: