[Openid-specs-ab] Issue #887: Multiple Response Types - Content that SHOULD be fragment encoded MUST NOT be query encoded (openid/connect)
issues-reply at bitbucket.org
Tue Oct 15 00:42:21 UTC 2013
New issue 887: Multiple Response Types - Content that SHOULD be fragment encoded MUST NOT be query encoded
We talked about this on the call today. I asked why responses are described as “SHOULD be fragment encoded”, rather than “MUST be fragment encoded” in the OAuth Multiple Response Types document. John said that the SHOULDs are to leave the door open for using PostMessage - not to allow query encoding.
He pointed out that the HTTP Referer header includes query parameters, and so any query parameter encoded content will leak to third parties. This is a huge security hole that is prevented by the fragment encoding.
The only OAuth value that can be safely query encoded is "code", and then when using a confidential client. That's OK because the Code is not useful to a third party that doesn't have the Client Secret.
The working group decided to clarify the specs to explicitly prohibit (MUST NOT) query encoding any parameters other than Code.
More information about the Openid-specs-ab