Add verification for password oauth token

[nanaya]

# reissue verification code
POST api/v2/session/verify/reissue

# verify token
POST api/v2/session/verify
parameter: verification_key (string)

On /me endpoint response, there's a new attribute session_verified.

Additionally, notification server will also send verification event when the verification link is opened ({ "event": "verified" })

• depends on Store session verification request data in redis #10796
• implemented and tested and released in client (Add two factor authentication flow osu#25480)

[notbakaneko]

A verified session sending verification_key to verify-session probably shouldn't be issuing a new verification code? 🤔

[notbakaneko]

Reminder ppy/osu-notification-server#55 also should be deployed after this is deployed.

[peppy]

Additionally, notification server will also send verification event when the verification link is opened

Given that we don't yet have any setup for notification server in the game yet, is it fine to ignore this for now? Do we need to poll or something to handle the scenario?

[nanaya]

ignoring it would confuse users. I guess a token status endpoint could be added...

[peppy]

Cancel that, we do have support for notification websocket handling (see https://github.com/ppy/osu/blob/27c497145f87449ac17c08796fc57026d3129f2e/osu.Game/Online/Notifications/WebSocket/WebSocketNotificationsClientConnector.cs#L16-L45)

But work on this will likely happen early next year from the client side, so let's leave this PR in limbo for now.

[bdach]

I would like to get started on this client-side, but I'm not sure I get what fits where exactly, so I'm gonna have a few questions here.

• From what I can gather, the basic flow is as follows:

  sequenceDiagram
      participant osu
      participant external web browser
      participant osu-web
      participant redis
      participant osu-notification-server
  
      osu ->>+ osu-web: GET /api/v2/users/me
      osu-web -->>- osu: 200 OK<br>{ ..., session_verified: false }
  
      note right of osu: User received verification e-mail
  
      alt verification code entered via client
  
          osu ->>+ osu-web: POST /api/v2/session/verify?verification_key=...
          osu-web -->>- osu: 200 OK
  
      else verification link clicked
  
          external web browser ->>+ osu-web: GET /home/account/verify?key=...
          osu-web ->>+ osu-notification-server: UserSessionEvent::newVerified->broadcast()
          osu-notification-server -->>- osu-web: ACK
          osu-web -->>- external web browser: 200 OK
  
          osu-notification-server --) osu: { "event": "verified" }
  
      end
  

  Loading

  Do I have that right?

• In this comment, the following was stated:

  Basically there will be a case where web will let us know via a response to any API request that we need verification, which will cause the client to bring up the prompt.

  Is this really the case here? Do I need to be potentially handling (re-)verification on any response? From source it kinda appears to me that it's only scoped to GET /api/v2/users/me but I may well be wrong.

• Do I need to be handling token revocation? As in, if a UserSessionEvent::newLogout() event is broadcast, do I need to be doing anything? Is that even something that can happen for a client token right now?

[nanaya]

I would like to get started on this client-side, but I'm not sure I get what fits where exactly, so I'm gonna have a few questions here.

• From what I can gather, the basic flow is as follows:

  Do I have that right?

seems mostly right. The newVerified event is always published regardless of the source. I don't think it matters much in the context of client though.

• In this comment, the following was stated:

  Basically there will be a case where web will let us know via a response to any API request that we need verification, which will cause the client to bring up the prompt.

  Is this really the case here? Do I need to be potentially handling (re-)verification on any response? From source it kinda appears to me that it's only scoped to GET /api/v2/users/me but I may well be wrong.

mainly only POST requests will return verification required response (exceptions etc applies). It's the same as web at the moment.

• Do I need to be handling token revocation? As in, if a UserSessionEvent::newLogout() event is broadcast, do I need to be doing anything? Is that even something that can happen for a client token right now?

a logout event means the session/token is no longer valid. One case would be when the user changes password (on web) it'll log out all other sessions and tokens.

technically even without handling it any further requests will be denied anyway but at least in osu-web a forced logout will be immediately applied.