Try MyIntelliAccount Cloud Accounting Software As A Service Solution Risk Fre...
Cloud Native App Security
1. Cloud Native App Security
IAM concepts for the cloud-native world
2. WHAT IS THE BEST SECURITY YOU CAN GET
WHEN WORKING WITH DISTRIBUTED
SYSTEMS?
Let’s start with a short question:
3. Security, as every architectural decision,
is always a trade-off.
There is no “perfect” security.
But relying on good practices can help.
Just to double-check: there is no silver
bullet.
4. @pinguwien
dguhr@redhat.com
linkedin.com/in/dguhr/
github.com/DGuhr
Who we are
Dominik Guhr
Over 10 years of experience as
a software engineer
/consultant / agile guy / PO
problem solver
Current: Senior software
engineer at the Keycloak
Team at Red Hat
Jonathan Vila
Java Champion, Organiser at
BarcelonaJUG, cofounder of
the JBCNConf conference.
Have worked as a developer
since the release of The
Secret of Monkey Island,
about 30 years ago. PMP
certified by the PMI in Project
Management.
Senior Software Engineer at
Red Hat at Keycloak Cloud
Native team.
@vilojona
jvilalop@redhat.com
aytartana.wordpress.com
github.com/jonathanvila
5. IAM , OAuth2 & OpenID Connect
Identity and Access Management (IAM):
Authentication / AuthN: Are you really you? -> proof of identity
Authorization / AuthZ: Are you allowed to access that? -> proof of permission
OAuth2:
JWT / token-based
Designed to answer the second question only
OpenID Connect (OIDC):
Secure AuthN Layer on top of OAuth2.
Generally two types of clients: public / confidential
7. Authorization code flow: Why it’s not enough?
1⃣ AuthN Request
2⃣ AuthN Request
3⃣ code
4⃣ code
5⃣ Token request
6⃣ Access Token
Pixies to the rescue!
8. PKCE: What is it, and why?
PKCE - “Proof Key of Code Exchange”
Initially for mobile / native apps, but now also recommended for SPAs by IETF
security extension of the authorization code flow
client verifier / client challenge
dynamically generated, secure “one-time” secrets
Goal: client which requests tokens is the same client who started the authentication
request
9. 0⃣ Generate Verifier,
code_challenge & method
1⃣ AuthN Request +
code_challenge & method
2⃣ Record code_challenge &
method used
3⃣ Return AuthZ Code
4⃣ Token Request w/o Verifier
5⃣ Check/Comparison fails.
6⃣ NOPE!
Authorization code flow with : How it works?
10. So… are we secure yet?
…
...
… let’s say we’re confident that this is good
enough.
(But have you heard of refresh tokens?)
11. refresh tokens & access tokens → bearer tokens
Bearer = Identity trusted - Access checked before
Browser = untrusted = “here be dragons”
Stolen :
● Refresh Token → exchange new token pair.
● Access_token → short time access.
Problem: Proof of Possession
Mitigation:
● Refresh token
rotation
Solutions:
● mTLS
● DPoP
13. “OK OK WE GOT IT!
BROWSER = HERE BE DRAGONS!
Can we just avoid leaking ALL tokens to the
front channel?”
14. Well… “yes, we can!” Let’s take a look at the BFF pattern.
15. Conclusion: BFF
Pro: No Tokens in the browser anymore! Yay!
Secure HttpOnly SameSite Cookie: Effective protection vs CSRF/XSS.
CON: Additional component = additional maintenance. (but BFF can be very simple)