Skip to content
This repository was archived by the owner on Dec 13, 2018. It is now read-only.

Unable to process openid connect response as fragment #1195

Closed
alvaradojl opened this issue Apr 29, 2017 · 6 comments
Closed

Unable to process openid connect response as fragment #1195

alvaradojl opened this issue Apr 29, 2017 · 6 comments
Labels

Comments

@alvaradojl
Copy link

alvaradojl commented Apr 29, 2017

Hello!
I'm developing a web endpoint protected by a legacy openid connect server,
the configuration on the client website (startup.cs) is the following:

` app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
            {
                AuthenticationScheme = "oidc",   
                SignInScheme = "Cookies",   
                ClientId = "client1", 
                GetClaimsFromUserInfoEndpoint = false,
                ProtocolValidator = new OpenIdConnectProtocolValidator() { RequireStateValidation=false, RequireState=false },
                ResponseType = "token id_token",
                ResponseMode= OpenIdConnectResponseMode.Fragment,
                Configuration = new OpenIdConnectConfiguration() { 
                    AuthorizationEndpoint = "https://server/oauth/v2/authorize" 
                }, 
                RequireHttpsMetadata = false, 
                SaveTokens = false 
            });`  

I'm obliged to set response_type as "token id_token" only.

After requesting an edpoint protected with the [Authorize] attribute, I correctly get redirected to the authorization server which provides a form for the user to login.
Once the user logs in, the authorization server returns a 302 to the client website appending a fragment with the access token and the id token.

Example:

`https://localhost:44341/signin-oidc#access_token=384b1c07-4a59-41e3-894f-266e46680f0c
&expires_in=3600
&token_type=Bearer
&id_token=<random_jwt>
&id_token_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&state=CfDJ8JU8TffTfA9Jnq6JVvmsltccnGVaA_IX4LQhGjz_n3f0NMqSBfcdctjtUAtDpCN7F4Wy9pqq8ikQo-KVpaQlOnOwPpqZWUDWfKeLvOeFQ9-GI6eq1RbE_13Hrtdwm1Ijy0N7nwmbuO47uK_Zg0NfzcfngHVvfUB0ccrAAE79EcKVaiuXXcwCQwtflsp1kFdCou4aJVY9zo2-w_wwTJpEuyw_c-WulPD3bY8ZQLiGpmt8Wao9VQsBmOBoMB-zCBf9o4ot2jloyqpnXamOx6mCFvWizxILvXVH1pbYEc58SFRKe4MSW3png8xSqTdN1gZ6iKBy6BPtq_v5XLsbL68cCng
&scope=openid`

I get an error from the openidconnect middleware (web client) saying:

OpenIdConnectAuthenticationHandler: message.State is null or empty.
AggregateException: Unhandled remote failure. (OpenIdConnectAuthenticationHandler: message.State is null or empty.)

The error is clear, it cannot find the state parameter, indeed, because it is not in the querystring anymore but on the fragment. However I explicitly set it to expect the response in the fragment. And even if this is not working, I also set an option to skip the state validation, but it doesn't work either.
I'm I missing something?

@brockallen
Copy link

fragments aren't sent to the server by the browser, so of course the middleware can't see the values. the use of fragment response mode in OIDC is most common with SPA/JavaScript-based clients, not server-side ones.

@alvaradojl
Copy link
Author

alvaradojl commented Apr 30, 2017

Hi Brock, but what's the point of allowing to set ResponseMode to fragment if there is no way the middleware can intercept it? and the same goes for the option RequireStateValidation, if those options are not possible then they should not be there in the first place, should they?

@brockallen
Copy link

You could use query or form_post for server-side code, although the spec prohibits using query with id_tokens, so it's unclear why they added this to the middleware for OIDC.

@kevinchalet
Copy link
Contributor

so it's unclear why they added this to the middleware for OIDC

Since I'm the guy who's added it, I can answer that: to support the good old code flow with servers that don't implement the form post extension 😅

@brockallen
Copy link

Oh yes, good point -- I had forgotten about code only flow.

@Eilon Eilon added the invalid label May 5, 2017
@Eilon
Copy link
Member

Eilon commented May 5, 2017

For the reasons described above, closing this.

@Eilon Eilon closed this as completed May 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants