getOfflineToken fails if there is a URL param about insights-chrome

[Hyperkid123]

@d-ramakri @jschuler OK, I have opened a PR with a path BUT, if @alechenninger says we should use the CLI auth then I would strongly recommend doing so and deprecating the doOffline and getOfflineToken functions. And eventually getting rid of them.

I assume that somewhere in your UI/QuickStart there is a guide involving getting the token and then pasting a command including the token somewhere in the user's terminal right? Is it possible to change the guides to include the CLIT auth?

[alechenninger]

Hey folks, there is some confusion here. That is not all the requests being made to SSO.

In your token request, the redirect URI has to be exactly the same as the redirect URI in the auth request: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3

In a test I observed:

Auth request redirect URI	Token request redirect URI
https://console.redhat.com/openshift/token/show?test=true&noauth=2402500adeacc30eb5c5a8a5e2e0ec1f	https://console.redhat.com/openshift/token/show?noauth=2402500adeacc30eb5c5a8a5e2e0ec1f

SSO is working as intended since these are not the same. However, still, no query variable query parameters should be used in redirect URIs, so ideally none of these are used and any variable information is passed and decoded from the state parameter maintained in the redirect.

Lastly, the whole process of getting an offline token so it can be pasted into a CLI is unnecessary and insecure. The CLI can and should authenticate the user directly such as by using the auth code flow and redirecting to a loopback address or by using the device authorization flow. I'm happy to discuss about this in more detail if you'd like outside of this issue.

Edit: To summarize:

• You can fix this quickly by simply using the same redirect URI in both auth and token requests
• Better would be to avoid passing query parameters at all, and use the state parameter instead
• Way better than either of those would be to not even get another token, and let the CLI do that itself

[jschuler]

Thanks @Hyperkid123 ! And yes I agree it would be wonderful to get rid of the clunky copying of token into the CLI step altogether, that would be preferable. I hope we can go down that path, but in the meantime thank you for the fix!

[Hyperkid123]

Well, I think might be an SSO issue.

We are sending a noauth query param with a hash. I just think the SSO does not expect any other query parameters so it just simply does not accept the redirect link with additional query parameters. It does not even accept hash in the redirectUri param.

@ryelo can we talk to SSO dev team about why not parameters are permitted?

[ryelo]

Yep I can send them a message to ask why we can't add additional params. My assumption is that we could, but we just have to put a blob in their config to allow it.

[kdoberst]

@Hyperkid123 @ryelo This issue is making development on the ROSA wizard more difficult - wondering where the conversation with the SSO team is at.

[jschuler]

This will also have an impact on other things that add URL params, like quick starts

[alechenninger]

Can someone paste the exact request that is being made to SSO?

Is the additional query parameter a part of the redirect URI? If so, this is not allowed, per https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2

To send variable state along with a redirect, you must use the state parameter.

[jschuler]

Here's an example of what I am observing at the moment:

• Navigate to https://console.redhat.com/openshift/token/show?test=true
• I see in the Network log:

Request URL: https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
Request Method: POST
Status Code: 400 

Payload:

code: 93ee20be-e714-46cc-93b1-d9b18362c6ad.1afcace9-6923-474b-8a2a-8f384876191f.78d5cce2-4b4b-419e-9007-28deefc1edaf
grant_type: authorization_code
client_id: cloud-services
redirect_uri: https://console.redhat.com/openshift/token/show?noauth=2402500adeacc30eb5c5a8a5e2e0ec1f

Response:

{"error":"invalid_grant","error_description":"Incorrect redirect_uri"}

[Hyperkid123]

as @alechenninger we will probably have to move the quickstart to the #state hash in the URL to get around the error. Essentially that will force use to sanitize the URL and the append the quickstart query param back once we are authenticated

[jschuler]

This is not just quick starts btw, this affects also the day 1 experience for new RH customers creating ROSA clusters.
They have to accept Terms and Conditions, which appends URL parameters as well. When they then try to get the token it fails.

URL looks something like this after they accepted the terms:
https://console.redhat.com/openshift/create/rosa/wizard?decision-1524=accepted&ackID=6071004376#

[d-ramakri]

How involved / complicated is the change @alechenninger @ryelo and who would do it? Sorry to pull the 'urgent' card - this issue is directly linked to a high priority / high visibility complaint from customers on the ROSA day 1 wizard for OCM HAC-1525