Support for hashes in the redirect URIs

[akellens]

Hi,

Our application makes use of hashes in the redirect uri.
For example: https://<some host here.com>/web/#/sso?code=<some grant code>.

It appears however that when trying to get a token from the code, the hash gets consumed so that the exchange is not possible.
I saw that this is a todo in the code, but perhaps there are some workarounds possible (in version 5 this worked fine as were able to pass the code directly to the openid-client)?

[panva]

https://<some host here.com>/web/#/sso?code=<some grant code> is not a URL that an authorization server can ever redirect to. But it is possible that's how your frontend "router" rewrites the URL.

For one it parses as the following, i.e. there are no query string components

> new URL('https://rp.example.com/web/#/sso?code=abc')
URL {
  href: 'https://rp.example.com/web/#/sso?code=abc',
  origin: 'https://rp.example.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'rp.example.com',
  hostname: 'rp.example.com',
  port: '',
  pathname: '/web/',
  search: '',
  searchParams: URLSearchParams {},
  hash: '#/sso?code=abc'
}

RFC6749 has this to say in https://www.rfc-editor.org/rfc/rfc6749.html#section-3.1.2 as well

The endpoint URI MUST NOT include a fragment component.

Which yours does #/sso.

Before I disect this further, what is the redirect_uri you use in the authorization requests?

[akellens]

Thanks for the quick response.
The redirect_uri we use is literally containing a hash (i.e., something like https://rp.example.com/web/#/oauthExchange?code=abc).
I was not aware of it, but the RFC indeed excludes this from being a correct redirect URI, so I think the only proper way forward is for us to remove it from the URLs. The hash was introduced a long time ago when state management of browsers wasn't ideal, but I don't see any reasons to keep it around. It worked in v5 of openid-client, but only by accident it seems.

[panva]

The redirect_uri we use is literally containing a hash (i.e., something like https://rp.example.com/web/#/oauthExchange?code=abc).

Your exact redirect_uri parameter value that you send TO the authorization endpoint is https://rp.example.com/web/#/oauthExchange?code=abc?

[akellens]

I was mistaken of course: the redirect we send is something like https://rp.example.com/sso/after_login.
This will then redirect the user internally (it does some state management) to another page that contains the hash.

It is that redirect that actually triggers the exchange of the token. My implementation of getCurrentUrl() (as per the example) should of course be the original redirect we got from the authentication service, and not my internal redirect URL, as that one is 1) not containing the query parameters, and 2) the wrong redirect uri entirely. 🙈

It worked in v5 of the client simply because there I passed along the code that was extracted from the original redirect after a user signed in.

[panva]

👍