OIDC consent uses harcoded scopes and doesn't allow remembering consent

[davidspek]

Summary

After #273 and #277 is should be possible to request the offline and offline_access scopes from an OIDC application. While the changes in those PRs make is possible for an OIDC app to request the offline and offline_access scopes, the refresh token is never returned. While logging the output of the returned token I discovered the response contains scope:profile openid, even though offline and offline_access were requested as well.

I believe the issue is caused be this line.

Simply adding the offline and offline_access scopes there might break existing OIDC apps, since those were created before #273 and #277 were merged and thus don't have access to those scopes.

I believe the scopes requested by the application should be forwarded to consent form, rather than having those be hardcoded.

Reproduction

Have an OIDC application request scopes other than openid and profile. While the OIDC login will complete successfully, scopes such as offline and offline_access are never returned.

[davidspek]

Looking into the code further, our GraphQL API doesn't seem to be returning the Consent Response from Hydra. We will need this so we can parse the scopes (requested_scope), as well as allowing users to remember their consent choice so they don't need to consent each time they log into the app.

[michaeljguarino]

are the scopes available in a query param? I can also write a job to update all the clients, which isn't actually that hard

[davidspek]

@michaeljguarino We still have the scopes hardcoded in the consent page, which makes it impossible to get the offline and/or offline_access scopes.

Here is an example of the Consent Response from Hydra:

{
  "challenge": "f633e49d56bc40e0a876ac8242eb9891",
  "requested_scope": ["openid", "offline"],
  "requested_access_token_audience": [],
  "skip": false,
  "subject": "foo@bar.com",
  "oidc_context": {
    "acr_values": [],
    "display": "",
    "id_token_hint_claims": {},
    "login_hint": "",
    "ui_locales": []
  },
  "client": {
    "client_id": "auth-code-client",
    "client_name": "",
    "redirect_uris": ["http://127.0.0.1:5555/callback"],
    "grant_types": ["authorization_code", "refresh_token"],
    "response_types": ["code", "id_token"],
    "scope": "openid offline",
    "audience": null,
    "owner": "",
    "policy_uri": "",
    "allowed_cors_origins": null,
    "tos_uri": "",
    "client_uri": "",
    "logo_uri": "",
    "contacts": null,
    "client_secret_expires_at": 0,
    "subject_type": "public",
    "token_endpoint_auth_method": "client_secret_basic",
    "userinfo_signed_response_alg": "none",
    "created_at": "2020-07-09T10:07:01Z",
    "updated_at": "2020-07-09T10:07:01Z"
  },
  "request_url": "http://127.0.0.1:4444/oauth2/auth?audience=&client_id=auth-code-client&max_age=0&nonce=shfxjszihgvbptswjbqsrdbg&prompt=&redirect_uri=http%3A%2F%2F127.0.0.1%3A5555%2Fcallback&response_type=code&scope=openid+offline&state=pmkekezifwwpgmzpckiqxzbt",
  "login_challenge": "de814daf9bbb4b788b505b3c2dd5ce20",
  "login_session_id": "c829da46-2041-400c-b72d-08324f878d0a",
  "acr": ""
}

The requested_scope should be passed to the consent page, rather than having them hardcoded. This way, the consent form will include the scopes actually requested by the application.

Along with that we should pass skip so we can skip the consent page if a user saves their consent choice.