Alternative Fragment Identifier

[Sephster]

An old pull request allowed us to replace the # with an alternative fragment identifier for the implicit grant. I am struggling to find where in the spec this is valid.

We need to check if this is valid as it could introduce a security concern should someone use a ? instead, which will convert the params to a query string and make them available to the server.

This might be completely valid but it would be good to find out where in the spec it allows this and reference this for future questions.

[sg3s]

I've had this exact question when I began devoting time to understanding all the different specs.

Fragment encoding in fact a part of OpenID specs. Definitely something you want if you want to work towards a fully OpenID Connect compliance.

The question is if that is something you/the maintainers want. The specs are backwards compatible with plain oAuth2 as far as I know, but might require significant changes to implement properly. For a large part OpenID specifies additions, so it could possibly be enabled by adding interfaces, traits for the extra entities and some extra configuration.

The specification describing (among other things) the fragment response type is I think one of the more divergent from plain oAuth2 but well understandable knowing the context of the original specs. http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

Personally I find these specs to be pretty hard to read, even compared to IETF RFCs, so for me this documentation of a OpenID Connect compliant server really helped me by framing the different features from an implementation standpoint. https://connect2id.com/products/server/docs/api

OpenID Connect is something I've been personally been looking into as it solves some additional problems we've been having trying to use oAuth2 for our 1st party clients. But it is not something you just do, and I am pretty time constrained. I see the questions for OpenID Connect features pop up pretty often here too, so maybe it should be something to invest in.

[sg3s]

To be complete; These are features that are in OpenID Connect that are pretty desirable to me:

• Fragment responses for authorisation requests
• Token introspection (using RFC7662)
• Token revocation (using RFC7009)
• Userinfo
• Login / session status through iframe
• Logout flows

And to complete/manage that it also includes:

• Server discovery (see it as feature detection for clients)
• Server JWK set (publish keys needed to validate tokens)
• Client registration (for dynamic clients, like apps)

I am not sure what a minimum implementation would be, but server discovery is definitely needed, and some features can be optionally exposed through server discovery.

Under "Specification Organisation" they list exactly what is optional and what is not. http://openid.net/connect/

[sg3s]

It seems that the fragment is supposed to be used when using Implicit Grant in the core oAuth 2.0 spec.

Though, I do think OpenID Connect does a much better job of defining how that actually works then.

[Sephster]

Thanks @sg3s. Yeah, I'm sure we need to keep this in, I'm just not sure we should be allowing people to choose different characters from a # as the pull request I'd referenced allows us to do. I can't find support for this in the spec but I do seem to recall reading about it somewhere at some point (although I am struggling to find any evidence to support this).

[sg3s]

Ah, missed that the PR made it an arbitrary character...

No that is definitely not right. The reason the fragment is used for the implicit grant is ofcourse to protect the token which stays local and is not sent to servers in requests by user-agents and thus does not show up in logs.

The spec that does expand this and does allow for another way is OpenID Connect - in the same document that I linked earlier response_mode is defined, and it is stated that the use of the option is not recommended. But if that spec is followed then the change should be based on the presence of the response_mode query param in the authorisation request.

It is not even mentioned in the original spec that you should be able to use a query string, even suggesting that for user-agents that do not support it in a Location header you should employ a different type of redirection. It does not mention switching over to using a query string, probably because this is inherently insecure for Implicit Grant responses.