Oidc-client-js: Support response_modes_supported

[CaptObvious]

The .well-known/openid-configuration supports a property response_modes_supported which can take either "query" or "fragment". oidc-client-js only seems to support "fragment", meaning it only looks in the URL after the #.

My OpenID provider (over which I have no control) only supports the "query" response mode, so it puts the details in the query string.

I'd do the work myself and send a PR, but my employment contract prohibits it 👎

[brockallen]

My OpenID provider (over which I have no control) only supports the "query" response mode, so it puts the details in the query string.

The protocol specifically disallows tokens from being sent in quest string params, so your token server is violating the spec if that's all it supports. That's also why this library doesn't support it.

[CaptObvious]

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

response_modes_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_mode values that this OP supports, >as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the >default for Dynamic OpenID Providers is ["query", "fragment"].

http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes

[brockallen]

I'd do the work myself and send a PR, but my employment contract prohibits it 👎

Also, shame on your company for using OSS without allowing contributions back. I know it's your company, and not you personally. Feel free to pass this feedback to them.

[brockallen]

response_modes_supported
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_mode values that this OP supports, >as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the >default for Dynamic OpenID Providers is ["query", "fragment"].

from that same spec:

code token
    When supplied as the value for the response_type parameter, a successful response MUST include an Access Token, an Access Token Type, and an Authorization Code. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode. 
code id_token
    When supplied as the value for the response_type parameter, a successful response MUST include both an Authorization Code and an id_token. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode. 
id_token token
    When supplied as the value for the response_type parameter, a successful response MUST include an Access Token, an Access Token Type, and an id_token. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode. 
code id_token token
    When supplied as the value for the response_type parameter, a successful response MUST include an Authorization Code, an id_token, an Access Token, and an Access Token Type. The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used. Both successful and error responses SHOULD be returned using the supplied Response Mode, or if none is supplied, using the default Response Mode.

[CaptObvious]

That only covers multi-type requests.

[brockallen]

So you're only doing response_type=token?

[CaptObvious]

response_type=id_token

[brockallen]

If you're only doing response_type=token, then you're not doing OIDC (see here: https://openid.net/specs/openid-connect-core-1_0.html#Authentication). Arguably, then, the multiple response type spec is not pertinent.

Anyway, the whole point of the specs not allowing it is to prevent access tokens from being exposed/leaked to server logs. Pedantic spec quoting aside, I won't be making that change to this library.

[CaptObvious]

It seems like this is a moot point anyway, it seems our OID server does support response_mode=fragment, it's just not listed in /.well-known/openid-configuration.

Now to figure out why I'm getting told that there's no state in the response even though there clearly is. Thanks for your help!

[roblapp]

I guess I am a little confused. By default IdentityServer4 gives the following response_mode values:

//Constants.cs
public static readonly List<string> SupportedResponseModes = new List<string>
        {
            OidcConstants.ResponseModes.FormPost,
            OidcConstants.ResponseModes.Query,
            OidcConstants.ResponseModes.Fragment
        };

But I see you mention above that the spec forbids tokens from being sent in query string parameters. Also, the end_session endpoint requires you to pass the id_token as the id_token_hint parameter if you want the post_logout_redirect_uri to work. What am I missing here?

Thanks!