Implement & Test SSO

[ajsarkar28]

AC:

• Update mobile sign-in to request the new device_sso scope, securely store the returned device_secret, and pass the secret back when revoking the session.
• Add a feature-flagged web view (ex. no appointments screen) containing a logged-in va.gov page to demo the mobile SSO capability.
  • LINK_URL_SCHEDULE_APPOINTMENTS=https://www.va.gov/health-care/schedule-view-va-appointments/

Identity SSO Token documentation

[TKDickson]

Testing notes:

• QA should make sure to test all supported credentials (MHV, DS Logon, etc)
• During logout of the mobile app, user will not be logged out of any website sessions they've opened. Timeout/logout of the web session will continue to be its own thing/not triggered by anything that happens in the mobile app.

[theodur]

While working on this, I noticed there will need to be some changes in the vets-website repo for this to work. The first part of the SSO process entails passing the scope=device_sso parameter to the sign_in/authorize endpoint. The problem is the mobile app doesn't directly call the sign_in/authorize endpoint, that happens in the login webpage when the user selects their login method. This means the actual API call to the sign_in/authorize endpoint and its parameters are out of our control, and is managed by the code in vets-website.

The way the parameters get passed to the sign_in/authorize endpoint is through what we pass to the login screen when the user taps the Sign in button in the app; then the code from vets-website parses those parameters and sends them along when it makes the request to sign_in/authorize. When I looked through the latest version of the authentication logic in the vets-website repo, I noticed they haven't updated the parameters that they're parsing and passing to the sign_in/authorize request to include scope. So even when we pass the scope=device_sso on our end, it's not being picked up on the webpage.

I have a draft PR up with a draft implementation that should work, I just can't test it as of now without the vets-website code being updated. I'll speak more on this in stand up tomorrow.

[theodur]

I reached out to the identity team, and they're going to make a ticket for parsing the scope parameter on the sign-in page. I'm moving this ticket to blocked for now

[theodur]

The identity team was able to add logic to handle the scope parameter was added to the sign-in page. Now the device_sso scope is being passed to the authentication API call and I'm able to receieve the SSO cookies. I was able to confirm the SSO session is being properly set in the Webview now. I confirmed this by visiting https://staging-api.va.gov/v0/user in the Webview and recieved data about the authenticated user that wouldn't be available if the user wasn't authenticated.

The issue I'm running into is regardless of which page I visit on the website that requires a user to be signed in, it redirects the Webview back to the sign in page. So even though API requests are recognizing the SSO session, the actual website doesn't recognize the user being logged in. SSO won't work as intended until the website is updated to recognize the SSO cookies and bypass manual sign in. I reached out to the identity team in the Slack thread where prior conversations tooks place, so hopefully that can be addressed soon, but as of now this ticket is externally blocked.

[theodur]

After syncing with the identity team, it turned out all we had to do was set the hasSession field in local storage to true. Now SSO seems to be working flawlessly. I'm going to leave the testing changes in my draft PR up for demo tomorrow, and then after that, I'll revert the testing changes, and open my PR for review