[82122] updates /revoke to take device_secret param

[bramleyjl]

Summary

• updates /revoke to take optional device_secret parameter
• if device_secret is present SessionRevoker will attempt to use to it to look up and destroy any other sessions that have a matching hashed_device_secret property

Related issue(s)

• Update /revoke endpoint to optionally take 'device_secret' token va.gov-team#82122

Testing done

• New code is covered by unit tests

Testing

1. Use an API ClientConfig, make sure to modify shared_sessions to true.
2. Log in multiple times to create multiple SignIn::OAuthSessions, then modify a session to have a matching hashed_device_secret to the current session you possess the device_secret for:

linked_session = SignIn::OAuthSession.first
hashed_device_secret = Digest::SHA256.hexdigest(device_secret)
linked_session.hashed_device_secret = hashed_device_secret
linked_session.save
SignIn::OAuthSession.where(hashed_device_secret: hashed_device_secret)
  => 2 results

3. Perform a /revoke call with the access token for your current session and the device_secret passed as a url param:

curl --location --request POST 'http://localhost:3000/v0/sign_in/revoke?device_secret=<device_secret>' \
--header 'Content-Type: application/json' \
--header 'Cookie: vagov_access_token=<vagov_access_token>'

4. Both sessions should now be deleted:

SignIn::OAuthSession.where(hashed_device_secret: hashed_device_secret)
  => []

What areas of the site does it impact?

• SiS /revoke

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[bosawt]

Looks good, I tested this and confirmed it removes all sessions with a shared 'hashed_device_secret'

Also I confirmed a refresh token is necessary to perform this, which eventually we may want to consider whether it's necessary or not in a 'device_secret' revoke, but for now we'll just make refresh token required