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