OIDC redirect ignores assumes existing query string


I’ve an app that relies on the collab oidc for authentication (https://services.humanbrainproject.eu/oidc)

When navigating to my app, if I don’t have a valid token, I get redirected to the oidc login web page (https://services.humanbrainproject.eu/oidc/login)

The url that was use to redirect me to the oidc login page is: https://services.humanbrainproject.eu/oidc/authorize?response_type=token&client_id=neurorobotics-ui&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2F%23%2F

You can notice that the redirect_uri contains an url without query string.

After having entered my credentials, the oidc login page redirects me to my web page with the new acces_token to be use by my app in the query string. The problem is that the oidc page is concatenating “&acces_token=…” to the redirect uri, even if no query string was defined yet.

The resulting url is: http://localhost:9000/#/&access_token=eyJhb… and it is not valid because of the ‘&’ shoudl be ‘?’.

The result is that the oidc code in my page from the collab bower components won’t detect the access_token in the query string, so it won’t use it, and threfore it will go back to the login page, resulting in a endeless loop navigating between the two pages.


Hello Claudio,

I assume you are using the implicit flow of OpenID Connect. For security reason, the access token is added to the fragment component of the url and not the query string: the fragment component is what comes after the # part of a url

In your case, you already have a fragment component which contains /, so the OpenID Connect server adds the access token to this fragment by adding &access_token=..., therefore the url you get from the server is actually valid:

       fragment starts ↴   ↙ second value is the access token
            first value ↑ 

The code handling the access token should extract it from the fragment and not the query string. Did you write this code or are you using a third party library?

Best regards,
Allan Francani


Hi Allan,

Thank you for the detailed response.
I was under the wrong assumption the access_token was expected in the query string.

Thank you and best regards,