This document discusses security challenges with modern applications and services and provides an overview of common standards and approaches. It outlines issues with traditional password-based authentication and session management in today's environment of mobile apps, microservices, and client-side applications. The document then introduces token-based security standards like SAML, JWT, OAuth2, and OpenID Connect, explaining how they address these issues through tokenization, delegation, and flexible authentication. It recommends relying on existing solutions like Keycloak that implement these standards to simplify security implementation and avoid potential vulnerabilities.

1. Security in the era of
modern applications and
services
JDD 2015 Kraków
Bolesław Dawidowicz
Engineering Manager, Red Hat

2. Me…

3. 10 years working at
Red Hat

4. Security team at Red Hat
(Middleware Products)

5. Keycloak
Open Source Identity and Access Management Solution

6. Agenda - Part 1
• Problems with modern security
• Why it used to be so simpler before…
• Modern requirements
• Token based security

7. Agenda - Part 2
• SAML 2 / Federation
• JWT (JSON Web Token)
• OAuth 2 & OpenID Connect

8. Agenda - Part 3
• How to make your life simpler
• Identity Brokering
• Externalising security
• Out of the box solution

9. So lets start

10. In the old days…
… all used to be simple ;)

11. Server Side Apps

12. Form based security
Cancel Login
Username
Password
Hash / Compare

13. Old Architecture
• Usually server side
• Passwords
• Simple session management
• Invalidate to logout
• Cookies

14. Not anymore…

15. Passwords
• Not easy to store and validate
• Hard to enforce using strong
and unique ones
• Problematic to pass around in
safe manner

16. New credential types
• Not always easy to adapt application to support them

17. Session Management
• Simple for server side applications
• Complex for mobile and HTML5 applications

18. External Users
• Other Companies
• Our partners or customers
• No access to their database
• Social Networks

19. Single Sign On

20. Single Sign Out
Invalidate all your sessions in one place

21. Mobile Devices
• Using app for 10 min every 2 months … and
remain logged in!
• Authentication within application
• Safe storage of credentials
• Cut of access when device is lost

22. OWASP
The Open Web Application
Security Project

23. OWASP
Top 10 Most Critical
Application Security Risks

24. #2 in 2013

25. Broken Session and
Authentication
Management

26. Tokens

27. Tokens / Tickets / Assertions

28. What is a token?
• (XML / JSON / Whatever) document with some
payload
• Information about user
• Name, organisation, roles, authentication
method, timestamp, lifespan, etc.
• Can be signed

29. Tokens are signed
• Ensure they were not tampered
• No one altered them in the meantime
• Trust them without additional check with issuer.
• Now communication overhead

30. Why Tokens?
• Decoupling authentication / authorization
• Not relying on specific method
• Mobile / Server Side and Client Side apps will
authenticate differently.
• How this info is passed around

31. Flexible
You can decide what they contain

32. Why Tokens?
• Contain any additional information needed
• Can have defined lifetime
• Can be invalidated or managed in central manner

33. Ok but still… why
tokens help?

34. Delegation of authentication
to dedicated and trusted
server / provider

35. Providing credentials to
only one selected entity

36. Cancel Login
Username
Password

37. Cancel Login
Username
Password

38. Typical Components

39. Identity Provider /
Authorization Server
• Stores user data and credentials
• Performing authentication
• Issuing, verifying and revoking tokens

40. Service Provider /
Resource / Resource Server
• Exposing data or operations to be accessed by:
• user
• application on behalf of the user

41. User / Client / Relying Party
• User (e.g. via Browser)
• Applications acting on behalf of the user
(e.g. Mobile App)
• Backend Service or App (e.g. Microservices)

42. In practice?

43. ACME

44. ACME
Token

45. ACME
Token
Here you authenticate
(providing credential).
Within company
firewall/VPN
Cancel Login
Username
Password

46. ACME
Token
Here you authenticate
(providing credentials).
Within company
firewall/VPN
Here you get access
(no credentials)
Cancel Login
Username
Password

47. ACME
Token
Here you authenticate
(providing credential).
Within company
firewall/VPN
Here you get access
(no credentials)
ACME remains
in control of shared
user information
Cancel Login
Username
Password

48. Web SSO
(Single Sign On)

49. Federation

50. SAML 2

51. SAML 2
• OASIS Standard
• Version 1.0 in 2001
• Version 2.0 in 2005

52. SAML 2 Facts
• XML token - verbose and heavy
• Complex flows, lot of different profiles
• Very mature and widely adopted
• Many binding types - SOAP for e.g.
• High learning curve
• Doesn’t fit mobile use cases well.

53. SAML 2 - Federation
• Authentication and authorization between
organisations
• Not sharing access or ownership to user data
• Trusting external Identity Provider

54. SAML2 is very widely
adopted
de facto standard

55. What is the issue with
SAML2 and mobile?

56. POST vs GET

57. There are ways to
workaround it…
… still it always remains a workaround…

58. Newcomers…

59. OAuth2 &
OpenID Connect

60. Modern security needs
• Client Side Apps (HTML 5 / JS / Stateless)
• Mobile Apps
• (Micro)Services / APIs

61. First of all..

62. Tokens! :)

63. Token standards
• Kerberos
• SAML 2
• JWT (JSON Web Token)

64. JSON Web Token

65. JOSE
• JSON Object Signing and Encryption
• Set of IETF open standards (RFCs)
• JWT - JSON Web Token
• JWS - JSON Web Signature
• JWE - JSON Web Encryption
• JWA - JSON Web Algorithms
• JWK - JSON Web Key

66. JWT (JSON Web Token)
• JSON Document
• Key [String] : Value [JSON]
• Wide choice of signing algorithms

67. Anatomy
• Simple JSON, Encoded in Base64
• Three parts
• Header
• Payload
• Signature

68. {
"alg": "HS256",
"typ": "JWT"
}
{
"iss": "joe",
"exp": 1300819380,
"human": true,
"over 18": true
}
eyJhbGciOiJIUzI1Ni
IsInR5cCI6IkpXVCJ
9.eyJpc3MiOiJqb2U
iLCJleHAiOjEzMDA
4MTkzODAsImh1b
WFuIjp0cnVlLCJvd
mVyIDE4Ijp0cnVlfQ.
0LtIxMRXW0VItgVq
hQGUJCEjzWpnXpt
QOWxn9wGDyW4
Header in Base64:
eyJhbGciOiJIUzI1NiI
sInR5cCI6IkpXVCJ9
Payload in Base64:
eyJpc3MiOiJqb2UiLCJleHAiOjE
zMDA4MTkzODAsImh1bWFuIjp
0cnVlLCJvdmVyIDE4Ijp0cnVlfQ
Header
Payload
JSON Web
Token

69. <header-base64>.
<payload-base64>.
<signature-base64>

70. All you need to
know! ;)

71. OAuth2

72. Who knows or used
OAuth2?

73. Everyone ;)

76. source: aaronparecki.com

77. OAuth2 - Some facts
• Many major companies behind it
• Google, Facebook, Twitter and etc.
• 2.0 incompatible with 1.x
• Becoming de facto standard security framework for
• Mobile Apps
• Client Side
• APIs / Services

78. Major usecase?

79. NOT for authentication
…

80. NOT for authorization
…

81. DELEGATION
protocol

82. Applications & Services
acting on behalf of the
user

83. OAuth2 Actors
• Resource owner - YOU! :)
• Client - application acting on your behalf
• Resource / Resource Server - APIs accessed by
Client
• Authorization Server - Place where you
authenticate and where tokens are being issued

84. Authorization flows
• Authorization Code - Server Side Application
• Implicit - Client Side and Mobile Apps
• Resource Owner - Directly using username /
password
• Client Credentials - For app related operations -
app identity

85. Authorization Code
Flow
Server Side Applications

86. Authorization Server Resource Server
ClientResource Owner

87. Authorization Server Resource Server
Resource Owner
Client ID
Client

88. Authorization Server Resource Server
Resource Owner
Authorization
Code
Client

89. Authorization Server Resource Server
Resource Owner
Authorization Code
Client ID
Client Secret
Client

90. Authorization Server Resource Server
Resource Owner
Refresh Token
Access Token
Client

91. Authorization Server Resource Server
Resource Owner
Access Token
Client

92. Implicit
Client Side & Mobile

93. Authorization Server Resource Server
Client

94. Authorization Server Resource Server
Client
Access Token

95. Authorization Server Resource Server
Client
Access Token

96. OAuth2 - Scopes
• During authorization user grants application access
with given scope
• e.g. Basic profile info only (full name & email)
• e.g. Information about all your social graph (friends
on FB)
• e.g. Write access to FB wall

98. OAuth2 - Token Types
• By Value
• By Reference
• Pointer to information
• Way to not send data outside of your network
• You could have Reverse Proxy translating those in
front of your APIs.

99. OAuth2 - Summary
• Is pretty generic
• Doesn’t define specific token standard
• Lacks on authentication and user info side
• Many consider it more “a protocol framework” then
protocol itself.

100. Scales and adapts
nicely
Just teach your (micro)Service to understand JWT!

101. Cancel Login
Username
Password

102. OpenID Connect

103. OpenID Connect
• Builds on top of OAuth2
• Adds two new flows
• Adds session management -
• e.g. Single Sign On & Out for HTML5 apps
• ID token
• User info endpoint
• Discovery & Clients self registration

104. Getting widely
adopted…

105. OpenID Connect is what
you should consider
For any new modern application

106. But… How do I deal
with all the legacy?

107. What is the easiest
way to approach it?

108. Shameless Plug!

109. Keycloak Project
Open Source Identity and Access Management Solution

110. Same concepts apply to
other available solutions

112. Identity Brokering

115. Here is your
Legacy

116. Here is your
Legacy
Here is your
modern stuff

120. Will handle legacy
infra integration
for you !!!

121. Externalise Security

122. Integrate with OOTB
Identity Solution

123. Remember OWASP?

124. Security is hard
Don’t reinvent (or reimplement) things yourself…

126. How does it work?

127. <button onclick=“keycloak.login()”>
Login
</button>

128. OOTB Client Adapters
• JBoss EAP & WildFly
• JBoss Fuse
• JBoss BxMS
• JavaScript
• NodeJS
• Mobile (Cordova / Native)
• Spring
• Tomcat / Jetty
• … custom …

129. What do you get?

138. Want to make it look like
part of your application?

139. Sure!

141. My users need to accept
“Terms & Conditions”
page during auth…

144. User Self
Management?

146. Let them setup OTP?

148. And much more…
… of stuff you don’t need to implement yourself

149. Some (of many) features
• Session management
• Identity Management (with UI screens)
• Security Defences
• Password policies
• User impersonation
• ….

150. Lot of things you could
implement badly…
and in insecure way

151. What remains for you?
• Configure client adapter
• Get (more) information from the token
• Call REST endpoints
• Obtain additional information
• Perform additional operations

152. Summary

153. Rely on existing
standards
OAuth2 and OpenID Connect likely will fit all of your
needs

154. Use existing frameworks,
libraries and OOTB
solutions
Will speed you up, help integrating with legacy
infrastructure and shelter from mistakes…

155. Don’t try to (re)invent
things yourself
In security area this is most likely very bad idea…

156. Hope This Helps

157. Thank You!
Questions?