Skip to main content

OAuth2 With Contextual Binding

I've blogged a few times regarding the trend of implementing Zero Trust and CARTA (Continuous Adaptive Risk and Trust Assessment) style journeys during typical Web single sign on flows.  I want to riff on that process a little, with an update on how to implement something similar for OAuth2/OIDC access tokens.

Why is this important? Well sometimes it is important to apply some context to a particular authorization flow.  Not all access decisions are the same.  Think of the following nuanced situations:

  • Two users with the same set of scopes, have different API consumption patterns
  • A particular user has downloaded a malicious app which alters the botnet reputation of the request IP address
  • A particular user has registered their work email address with a site that experienced a credentials breach
  • A media site is behind a paywall and limits access to organisational IP ranges, but a user frequently works in the field
These sorts of flows, are a little bit different to the standard Proof of Possession flows, where client binding is done via a PKI infrastructure and tokens end up being issued, that are essentially customised.

I want the ability to capture some extra info during login and bake that into my tokens, in case that information will impact in some way, how the resource server or gateway actually fulfils the access request, above and beyond any scopes that have been assigned.

Implementing this in ForgeRock, requires a few subtle enhancements to different parts of the OAuth2 access journey.

Firstly, I need to capture some context - where should I do this and what context to capture?  Well, with Intelligent Authentication Trees, it seems sensible to start there.  With regards to what to capture, for the case of a demo, I'm simply binding a request IP address.  Other context attributes could include device characteristics, mobile SDK capture, 3rd party threat intelligence data or info from user behaviour SDK's.  

Here is a basic tree, that captures the IP and hashes it for some level of privacy preservation and "spoof proofing".




Logging in via this tree, then viewing my session properties, will result in some nice extra pieces of information.  This session information is clearly quite volatile and will change every time the user logs in, or the external information changes.


So the most interesting field is contextIP - a SHA256 hash of 127.0.0.1.  We'll use that next.

So on my OAuth2 provider, we now switch on the Customizable Access Token component - this is essentially a scriptable component that allows me to alter the contents of an issued OAuth2 access token.



Editing the script is pretty trivial and follows very much along the lines of the OIDC scripted claims feature.  In this case, I just add a simple claim that maps the session property set during authentication and adds into my access token.



For more information on the OAuth2 Customizable Access Token scripted API see here.

So now (and assuming I've gone through the authorization code flow with a server side session) my newly minted OAuth2 access token will look something like the following:


Note now, we have a contextIP claim - that is again the SHA256 hash of my IP at authentication time.  The nuances, between authentication time versus authorization token issuance time could be discussed at length, but for the case of this demo it works OK.  You could argue it could be gone during the authorization code to access token exchange.

My resource server (in this case ForgeRock Identity Gateway) would now, not only validate my access token - eg checking signature, nbf, exp and scopes - but would then do a context validation check - checking current IP address of the access token presenter, with that is baked into the token.

My next blog will show how IG can be configured to do that check and what options IG could leverage if any differences were found.  I'm going to following the D5 methodology here - namely deceive, destroy, degrade, deny or disrupt.

Comments

Popular posts from this blog

WebAuthn Authentication in AM 6.5

ForgeRock AccessManagement 6.5, will have out of the box integration for the W3C WebAuthn. This modern “FIDO2” standard allows cryptographic passwordless authentication – integrating with a range of native authenticators, from USB keys to fingerprint and facial recognition systems found natively in many mobile and desktop operating systems.
Why is this so cool? Well firstly we know passwords are insecure and deliver a poor user experience. But aren’t there loads of strong MFA solutions out there already? Well, there are, but many are proprietary, require complex integrations and SDK’s and ultimately, don’t provide the level of agility that many CISO’s and application designers now require. 
Rolling out a secure authentication system today, will probably only result in further integration costs and headaches tomorrow, when the next “cool” login method emerges.
Having a standards based approach, allows for easier inter-operability and a more agile platform for change.
AM 6.5 has int…

Implementing Zero Trust & CARTA within AM 6.x

There is an increasing focus on perimeterless approaches to security design and the buzzy "defensive security architectures".  This blog will take a brief look at implementing a contextual and continuous approach to access management, that can help to fulfil those design aspirations.

The main concept, is to basically collect some sort of contextual data at login time, and again at resource access time - and basically look for differences between the two.  But why is this remotely interesting?  Firstly, big walls, don't necessarily mean safer houses.  The classic firewall approach to security.  Keeping the bad out and the good in.  That concept no longer works for the large modern enterprise.  The good and bad are everywhere and access control decisions should really be based on data above and beyond that directly related to the user identity, with enforcement as close as possible to the protected resource as possible.

With Intelligent AuthX, we can start to collect and s…