token endpoint needs time tolerance for client_assertion iat claim

[delfuego]

token endpoint needs time tolerance for client_assertion iat claim

[mitchellhenke]

Thanks for opening an issue on this!

It's something we've seen issues with in the past, so I've created a ticket internally for us to evaluate whether we can remove the strict validation.

[delfuego]

That’s awesome! As it stands, there’s no simple integration with node and express that doesn’t include the claim in a way that cannot be overridden without forking the entire openid-client code base. So it’d be nice to see this relaxed on the part of login.gov!

[delfuego]

Just in case others find themselves here, I figured out a (suboptimal) workaround given that it looks like the way iat gets validated by identity-idp is pretty basic — it just has to be a number and has to be the current time or earlier. That's it. So all you have to do is make sure that iat is any time prior to the current time, and validation will succeed.

The only way to affect the iat claim with openid-client's provided Passport strategy is a way available at the time you construct the strategy — so you can't set iat dynamically at the time of an authentication attempt. At construction time, you can pass in extra parameters, one of which (clientAssertionPayload) is an object that gets merged into the object that forms the client_assertion parameter to the token call. So, for now, all I'm doing is setting clientAssertionPayload.iat to the current time at the moment I construct the strategy; then, at the time of an authorization attempt, it gets merged in to override the potentially-problematic iat. It seems to work perfectly... for now.

So, this is how I construct and use the new strategy (after having created my Issuer.Client loginGovClient and setting up my strategy params strat_params):

const loginGovStrategy = new Strategy({
		client: loginGovClient,
		params: strat_params,
		extras: { clientAssertionPayload: { iat: Math.floor(Date.now() / 1000) }
	}}, function(tokenset, userinfo, done) {
		console.log('in passport oidc strategy');
		// whatever you're going to do here
		return done(null, userinfo);
	});
passport.use('oidc', loginGovStrategy);

Hope this is helpful to others, until perhaps the iat strict validation can be relaxed at bit on the login.gov server side!

[panva]

@delfuego as an aside, if a given profile allows you to omit iat altogether - just pass the value as undefined during strategy initialization and the claim will be omitted from all future asssertions.

[panva]

I'm using the node openid-client library to authenticate to login.gov, and on initial implementation, I struggled with failures — the entire flow through to the token endpoint would complete, but then the token endpoint was returning an error reporting an invalid client assertion iat value. (I recognize that the login.gov spec doesn't say iat is mandatory, but it's a valid claim in the OIDC spec and the openid-client library includes it in all callbacks to the token endpoint.)

Debugging it in the openid-client library, if I eliminated the iat claim, everything then succeeded; if I kept it in, and subtracted a single second from it, it also succeeded. So, it looks like there might be some incredibly strict time intolerance on the login.gov platform somewhere that would be worth loosening.

(Note that in the OIDC core spec section 3.1.3.7, point #10 says it is entirely client-determined what range of values for iat to accept; it feels like login.gov might be enforcing a restriction that doesn't even allow a single second's difference between a client's system clock and the login.gov server clock.)

Steps to reproduce the issue (please be as specific as possible)

1. Initiate an OIDC authentication to login.gov, and then at the token request step, include an iat claim in the client_assertion that is set to the exact current unix timestamp.

Expected behavior

1. The token request would succeed.

Actual behavior

1. The token request fails with an HTTP 400 and an error "Client assertion invalid iat".

in the OIDC core spec section 3.1.3.7 point 10 is irrelevant for this discussion as it talks about ID Token validation, not client assertion JWTs.

What's relevant is

• https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12#section-3
• https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
• https://tools.ietf.org/html/rfc7519#section-4.1.6

iat
OPTIONAL. Time at which the JWT was issued.

6. The JWT MAY contain an "iat" (issued at) claim that identifies
   the time at which the JWT was issued. Note that the
   authorization server may reject JWTs with an "iat" claim value
   that is unreasonably far in the past.

There are OIDC profiles that require iat to be present (FAPI) which is why i rather include it all the time.

[delfuego]

@panva I tried to set iat to undefined at strategy initialization, and as far as I can tell, it doesn't work — the iat that's set in helpers/client#authFor still carries all the way through to the client assertion JWT. (But if there's further debugging, we should probably take this back to your project's issues rather than continue the thread here in identity-idp.)