module requesting token endpoint twice with same auth session on azureAD - rejected

[nneul]

I've been trying to work on replacing mod_auth_mellon (SAML) with mod_auth_openidc with AzureAD. I've got the latest release installed 2.4.9.4-1~focal+1 which did not change behavior from 2.4.1.

The symptom I am seeing is that the auth is randomly failing.

What I see in the log is:

"error_description":"AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token. ...<snip>..."

When I turned up debug log in apache, what I'm seeing is:

1. http_call to wk openid config
2. http_call to token endpoint -> gets a valid token in response for scopes "profile openid email User.Read"
3. http_call to keys endpoint
4. http_call to https://graph.microsoft.com/oidc/userinfo endpoint
5. http_call to token endpoint -- with exact same parms as item 2 above - this one is rejected indicating that the access code has already been used (message above).

Any suggestions here?

It looks like I MIGHT be able to make the problem go away by not having two top level protected paths on the server - but that isn't ideal.

Right now, I've got a /oidc/ path with nothing in it other than the redirect_uri, and another path, call it /protected/ that has actual content. On some instances (not yet configured), I may have /protected1/, /protected2/, etc. -- but the important thing is that the entire server or top level prefix is not always protected, only some paths on the server.

It also makes it much more of a pain from a documentation standpoint if I don't set aside that /oidc/ path since then I have to have different configured redirect_uri prefixes for different apps.

[zandbelt]

it looks like some parallelism is going on and it appears that your app is not a plain static HTML app? It would be interesting to see what (2) incoming requests are leading to this behaviour since I'm guessing that the "code" is delivered twice to the module.

[nneul]

I don't want to say this definitively (and I'm not sure it's 100%), cause it doesn't make much sense - but I'm including it here just in case it triggers anything in your knowledge of the code paths. It felt like the symptom is not seen (or at least reduced significantly) if I change from:

OIDCRemoteUserClaim upn ^(.*)@umsystem\.edu $1

to

OIDCRemoteUserClaim upn

with no other changes. Is there any chance that the pattern match against the claim is triggering another pass through the token retrieval that doesn't get hit when it uses the full claim?

[nneul]

@zandbelt I'm happy to share a full debug trace privately if that helps any, but would rather not post it on open discussion.

[zandbelt]

you can send a full (clean, from restart) debug log to [email protected]

[zandbelt]

the problem seems to be indeed with pcre_subst i.e. when using the 3rd parameter to compose a remote username; in your case you don't need that and you may just remove the 3rd parameter

I'll have to wrap my head around why this fails since input that worked before now fails; my best guess right now is that it has to do with the linkage of libpcre, to be continued...

[nneul]

Initial testing that does look like it's working, will try out a bit more widely and see if that's sufficient. Thank you!

[zandbelt]

this is fixed in 2.4.9.5rc5 e77cf94 thanks