769 nonce

[caesterlein]

Login.gov requires a nonce field to be generated for each session.

This is a first pass on using the session id to generate a random 32 character string. We store this IN MEMORY until we get it back (which should be almost immediately) and then remove it. We met the basic requirements specified by login.gov but going forward we may consider using a hash instead of a random number generator.

From login.gov docs-

nonce
A unique value at least 32 characters in length used to verify the integrity of the id_token and mitigate replay attacks. This value should include per-session state and be unguessable by attackers. This value will be present in the id_token of the token endpoint response, where clients will verify that the nonce claim value is equal to the value of the nonce parameter sent in the authentication request. Read more about nonce implementation in the spec.

From OpenId spec-

15.5.2. Nonce Implementation Notes
The nonce parameter value needs to include per-session state and be unguessable to attackers. One method to achieve this for Web Server Clients is to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value.

Also it looks like Spring Security 5 planned to support it but recently dropped it to the backlog
spring-projects/spring-security#4442

Also an old spring library offers an in memory nonce service we could think about using.
InMemoryNonceServices
closes #769