Jacob has a horse named Travis. The document discusses establishing trust in a microservices architecture through the use of claims instead of directly passing user attributes between services. Claims assert attributes about a user from a trusted source, rather than just providing the attributes alone. This allows services to verify the source of identity data and establish an authorization model with scopes. The document advocates using claims and centralized trust models to avoid issues that can arise from directly sharing user data between loosely coupled services without context.
11. The problem with API Keys and Basic Auth
• Machine verification(ish)
• User isn’t bound to the requested resource
• Authentication only, no Authorization
12. API Security Maturity Model
API Keys and Basic Authentication
Token based Authentication
15. Example: The publisher
Inside organization
Web Content
The Internet
Authorization: Bearer AT
Authorization: Bearer AT
Authorization: Bearer AT
16. The problem
• Access Tokens only used for authentication
• Authorization is not performed
• Machine access to the same API
• Result: Anyone who could obtain a token can update the content API.
17. API Security Maturity Model
API Keys and Basic Authentication
Token based Authentication
Token based Authorization
18. Scopes
• Named “permissions” in a token
• Strings
• Does not contain any values
• Requested by the client
• Authorized by the user and the OAuth server
31. Who do we trust?
• The caller?
• The API Gateway?
• The issuer of the tokens?
• The user database?
32. Trust
Trust is a subjective assessment of another’s influence in terms of the extent of
one’s perception about the quality and significance of another’s impact over
one’s outcomes in a given situation, such that one’s expectation of, openness
to, and inclination toward such influence provide a sense of control over the
potential outcomes of the situation.
Romano D.M. (2003). "The Nature of Trust: Conceptual and
Operational Clarification". Louisiana State University, PhD
Thesis.
33. Trust, in other words
• Trust is subjective
• It does not guarantee absolute truth
• It helps us predict the correctness of a decision
47. Hey, I can use a JWT
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJqY
W5lZG9lQGV4YW1wbGUuY29tIiwibmFtZSI6IkphbmUgR
G9lIiwiaWF0IjoxNTQ2MzAwODAwLCJleHAiOjE4OTM0N
TYwMDB9.XcNkubx0GNwbOohJGVAUVxl187oYSR0ecFz
0wvHvksOsOW9m6z3WyW4-
Q_yZUMuJaq_WZCX0y8EIUj9bur7aVfSONKv2uS_m7Cn
h_GlAAXFRkLZk9cBg3Xrv8mF2rcmZMy_0l5RdRDzF48H
35agZoImUR8sfPU-
S7ypgSmNX0j3nlLJLZNqjjF2XkFr54rNsXYFBQZUunzBgV
moeqfWRKcSB-
HJOrSWEiKL8JLMp8qgS0x4h5YRVtNiJ5o7I3KDYVGG4bw
ExFFPwHakseTdjkRJOGcUu1P5-
8DoLnsp1JLYbpfGLC3ebO1rRLQYuDDkqEmqzrMXTyXXT
8Lg8I2IkBw
{
sub: janedoe@example.com
name: Jane Doe
iat: 1546300800
exp: 1893456000
iss: https://login.curity.io
subscriber_id: ABC_123
}
48. A JWT has Claims
{
sub: janedoe@example.com
name: Jane Doe
iat: 1546300800
exp: 1893456000
iss: https://login.curity.io
subscriber_id: ABC_123
}
These are claims!
49. A JWT has Claims
{
sub: janedoe@example.com
name: Jane Doe
iat: 1546300800
exp: 1893456000
iss: https://login.curity.io
subscriber_id: ABC_123
}
There’s a subject
50. A JWT has Claims
{
sub: janedoe@example.com
name: Jane Doe
iat: 1546300800
exp: 1893456000
iss: https://login.curity.io
subscriber_id: ABC_123
}
Issued by
51. Using the JWT
The issuer / authority
The relying partyThe requesting party
Verify signature
JWT
60. Claim data
• Organize sensitive data to be reachable only by the OIDC server
• Include identity specific data in the token
• Use Opaque tokens on the internet and JWTs internally
• Only add data when the client needs it!
61. How to identify data to put in the token
• It should be relevant to a large set of your APIs
• It should not be application specific
• It should be attributes of the user
• It should not be contextual for the session
I’m going to talk about something important today.
But in order to get there, we need to take a step back and look at what the security model looks like today.
Part 1. The API Security Maturity Model
So bear with me, when we first dive into some examples, to build up the model that we can dive into later in part 2
I can present myself in many ways. If I use this photo as a basis, we could add some basic info that makes sense.
One example is when I buy clothes. The store doesn’t really care if I’m actually 38 years old, or if my shirt size is 48.
They don’t call the police to check that I’m really who I say I am.
As long as I pay…
Context? – where to ship to?
So, I guess there’s no issue here…
We’re getting ahead of ourselves a bit!
Lets leave that example for a bit now and lets take a historic look at where we stand
I’ve defined a model for how we can categorize the maturity of API Security
The basic level is where you protect your API using only APIKeys and Basic Authentication. Essentially this means that you are protecting the API itself from being called from unauthorized clients, but you are not protecting the API from incorrect usage or malicious usage
Token based Authorization = Scopes
The API is protected with system credentials
Network security policies
Not reachable from the outside
Token based Authorization = Scopes
Lets side track slightly.
Some of you who have worked with OAuth before probably know this.
Lets side track slightly.
Some of you who have worked with OAuth before probably know this.
They used certificate pinning to lock down the caller of the API.
However you can decompile the app to retrieve the certificate
Then endpoint then was used to retrieve the payment history
The call was authenticated, but not authorized properly
It was possible to replace the phonenumber and retrieve the payment history of anyone with an account at swish
To add complexity to the problem, we should remember that we pass a lot of information around.
It’s rarely one system involved when building complex services.
Give a few examples. Simple to more complex
To add complexity to the problem, we should remember that we pass a lot of information around.
It’s rarely one system involved when building complex services.
Give a few examples. Simple to more complex
Spaghetti of trust
In swish, the API trusted the App to provide the correct phone number.
Token based Authorization = Scopes
We don’t trust the gateway (particularly)
Give examples of where we trust the wrong part? Aftonbladet. Bank example of altered account number.
Who can modify the input?
What is trust?
We use it all the time. HTTPS.
Subjective = we can define what we trust in our own systems
The issuer
The enforcing party
The relying party
The information sources
Trust is subjective, we must create our own limitations and boundaries to make trust mean something
https://en.wikipedia.org/wiki/Computational_trust
I can present myself in many ways. If I use this photo as a basis, we could add some basic info that makes sense.
How do you know this is my son?
Two authorities can assert my attributes:
The police who issue passports, which includes my name, length and age
The tax authority who knows where I live, and that my son is my son.
But I don’t always need to prove who I am to the depth of these authorities.
1 . This would make it pretty pointless to pass data at all since verifying it all the time is cumbersome
Usually there are more than one source of data, so more knowledge about where data came from is needed.
2. Trust a common party with the most important data.
Two common methods:
Ask someone we trust to give it when we need it.
How do they know we entitled to get the data?
* Sign it.
The issuer
The enforcing party
The relying party
The information sources
Trust is subjective, we must create our own limitations and boundaries to make trust mean something
https://en.wikipedia.org/wiki/Computational_trust
The issuer
The enforcing party
The relying party
The information sources
Trust is subjective, we must create our own limitations and boundaries to make trust mean something
https://en.wikipedia.org/wiki/Computational_trust
It’s not the cars that make it safe to drive. It’s the rules
Information sources
Limit who can obtain data from valuable sources
Here’s the kicker : Only include the data that you know the client will need. A good OIDC/OAuth server will allow you to do this
