Risk Based Authentication is being promoted all around identity and is a great way to increase assurance levels with minimal friction. But what about machine to machine flows, that are still stuck in the credentials era of client_id and client_secret? Can we improve security of the tokens and enrich them with some context without resorting to full Proof-of-Possesion solution? Turns out… we can!
The signals
Well, let’s look at the signals that we could potentially use. UEBA (User and Entity Behaviour Analytics) goes out of the window, as there’s no context of a user anymore, but that doesn’t mean we cannot treat OAuth2 clients somewhat as… users. I am of an opinion that one should not create machine accounts by creating human accounts with complex passwords, but it’s ok to convert them the other way round, just for the purpose of the risk assessment.
Hardly any identity vendor protects the /authorize and /token endpoints from malicious consumption. Try to brute force a client credentials grant and you will find nothing stops you in your tracks. PingFederate blocks the client according with its user (!!!) password lockout policy, for a given source IP address (where the call was initiated from). This may potentially lead to toxic configuration combinations, if your stack sits behind a firewall (or in a container) that NAT’s the incoming connections to itself (single IP) and x-forwarded-for header is not used for harvesting the source IP address. I know of enterprises that are vulnerable to effectively a Denial of Service attack due to this misconfiguration.
Blocking the traffic and locking accounts was great 20 years ago, but today we consider it a bad customer experience. Imagine, me logging in to my wife’s Apple ID with bad password n-times and the iCloud services immediately stop working on her phone. Believe it or not, that is still the case today! Anyone can be a menace to anyone, all you need to know is the email address of your victim. The unlock procedure is lengthy and includes captcha, re-entering AppleID, SMS OTP and can even finish on the iPhone itself, where you have to unlock it – twice!
IP reputation
No problem here, the requests are coming from a specific IP, we can still use it for reputation assessment. Why not taking into consideration if the request is coming from a known botnet or TOR? Under normal circumstances, you are unlikely to hit many false positive conditions.
Brute Force, Credential Stuffing and Password Spraying
Think of the client_id’s as humans. If there’s a malicious actor trying to spray credentials across various applications, it doesn’t really matter if it’s against a user account or machine account. The methods are the same.
It’s ok if you don’t want to deny the attempts. But what you can also do is add the risk score to the token. If a particular request is made from a source that has a suspicious amount of requests across many client_id’s in a function of time,
The Token 2.0
From now on our JWT will contain more information, that links to the risk of the context they have been issued with. I built this example logic into ForgeRock’s Identity Cloud solution, using IP Quality Score service. I have created a custom token modification script and attached it to my client_id inside the native AM console. The script makes an API call to check if the source IP is anonymized or has a poor fraud score. The result looks something like this:
{
“sub”: “clientid1”,
“cts”: “OAUTH2_STATELESS_GRANT”,
“iss”: “url_of_the_authz_server”,
“tokenName”: “access_token”,
“token_type”: “Bearer”,
“aud”: “clientid1”,
“grant_type”: “client_credentials”,
“scope”: “somescope”
“exp”: 1666286007,
“expires_in”: 3600,“fraud_score”: 80,“recent_abuse”: true,“active_tor”: true}
As you probably noticed, this baddie comes from TOR, is known for being naughty and has been reported for abuse. Yes, they had the credentials, but that doesn’t mean much these days.
The Intelligent Resource Server
The resource server (or any other entity acting on behalf of it – i.e gateways and proxies) will now not only need to validate the token, check the signature or call introspection endpoint, but also look into the risk score or other attributes. If you’re trying to carry out a critical operation, perhaps obtaining the token from TOR, doesn’t warrant fulfilment. Long story short, access will be denied.
The downsides
As with anything, there’s the ugly. If you’re in any real-time business, like financial services or transactions, you will try to shave the latency wherever you can. Adding an API call to each credentials grant means additional milliseconds. Perhaps PoP would be a more suitable solution to strengthen the flow.
Balance in security is everything, so choose the right solution for your use case.