How not to send the `state` parameter?

[amessinger]

Hi there! Thanks for creating & maintaining this gem :)

I'd like to prevent this client from sending the state parameter during the request phase because in some cases I can't rely on the session to store it.

I thought the require_state config option set to false would do the trick but it seems to be used only for validation during the callback phase :

omniauth_openid_connect/lib/omniauth/strategies/openid_connect.rb

Line 123 in b56629d

invalid_state = (options.require_state && params['state'].to_s.empty?) || params['state'] != stored_state

)

From what I understand, the state parameter is still sent during the request phase, the identity provider forwards it back to the callback URL and this state value in the URL's parameters, though valid, can't be matched to the session's state value since the session is not available.

Couldn't the creation of the state parameter be made conditionally to the value of the require_state config option?

omniauth_openid_connect/lib/omniauth/strategies/openid_connect.rb

Line 178 in b56629d

state: new_state,

          [..]
          state: (new_state if options.require_state),
          [...]

Any help would be appreciated!

[stanhu]

@skycocker @syakovyn @bufferoverflow I think require_state was added in #127. Do you see any reason why we couldn't simplify this via:

diff --git a/lib/omniauth/strategies/openid_connect.rb b/lib/omniauth/strategies/openid_connect.rb
index ebfaaa1..6d80a66 100644
--- a/lib/omniauth/strategies/openid_connect.rb
+++ b/lib/omniauth/strategies/openid_connect.rb
@@ -120,7 +120,12 @@ module OmniAuth
       def callback_phase
         error = params['error_reason'] || params['error']
         error_description = params['error_description'] || params['error_reason']
-        invalid_state = (options.require_state && params['state'].to_s.empty?) || params['state'] != stored_state
+        invalid_state =
+          if options.require_state
+            params['state'].to_s.empty? || params['state'] != stored_state
+          else
+            false
+          end
 
         raise CallbackError, error: params['error'], reason: error_description, uri: params['error_uri'] if error
         raise CallbackError, error: :csrf_detected, reason: "Invalid 'state' parameter" if invalid_state

I'm not sure if state is being used somewhere else, but if it's just forwarded back, there's no use in generating it?

[stanhu]

Oh, I see that was proposed in #127 (comment).

The issue here is that if the state is generated by the authorize_uri, chances are the OpenID provider will pass it along. So maybe we should have gone with the original implementation?

[amessinger]

Hi! Thanks for looking into this.

In the mean time, I've gone ahead and made a working though naive implementation of a solution introducing an additional send_state config parameter.

I went with this solution because I didn't want to alter the behavior of the require_state config parameter.

amessinger@2a2510c

Hope this helps!

[stanhu]

Yeah, I'm trying to avoid adding yet another config parameter here, plus clear up some confusion about how require_state is supposed to work. I'm not sure how require_state ever worked as false because stored_state will always have a value since new_state always sets the value to some random value.

[stanhu]

I submitted #181 to fix require_state. Please feel to review.

[amessinger]

Thank you @stanhu for this!

The fix you're proposing allows me to complete my scenario of a stateless user agent which is not able to forward the state parameter for reasons out of my reach (aka my client's app :) ).

I think my initial intention was to prevent sending the state parameter during the request phase and make it so that it would not be expected during the callback phase.

I realize the "prevent sending de state parameter" part is more of a nice to have for me. It appears to be something the OIDC specs you mentioned in your PR aligns with me about base on the use of the "RECOMMENDED" key word.

That being said I understand that this library might wish to very slightly deviate from the specs to enforce good practices.

Please forgive me if I appear picky, I think this research and write up also serve me as a learning exercise on the subject.

Have a great rest of your day and thanks again!

[stanhu]

I think my initial intention was to prevent sending the state parameter during the request phase and make it so that it would not be expected during the callback phase.

@amessinger Thanks, we could consider using require_state to stop sending state as well. https://openid.net/specs/openid-connect-core-1_0.html says this about the authentication response:

state
    OAuth 2.0 state value. REQUIRED if the state parameter is present in the Authorization Request. Clients MUST verify that the state value is equal to the value of state parameter in the Authorization Request. 

A OIDC provider that drops the state from the response is thus not conforming to the spec.

[amessinger]

I think your interpretation of the specs is correct.

Maybe require_state could then be renamed send_state since, as I understand, the action of checking the state parameter would become a consequence of the client sending it in the first place?

Or maybe a more encompassing name would be more appropriate such as use_state or enable_state. I understand such a change would be breaking the API of the library so this might not be worth the hassle...

[BobbyMcWho]

Let me know whenever y'all are ready for the PR to be merged. I'll have to double check to see if this is one of the Omniauth libraries that I actually have rubygems release privileges for.

[syakovyn]

I am sorry, but I have an issue with the decision made.

I have the 2 scenarios:

1. The service provider sends a state to the IdP and expects it back. I'm expecting the IdP to return the sent state back.
2. The IdP makes a direct request to the service provider without the state. No state check is expected here.

With the previous implementation, I could cover both cases with require_state = false.
Now, there is no check in the first case with require_state = false, or the check fails in the second scenario when require_state = true.

I would be happy with any suggestion that can cover both cases.
Probably, send_state or verify_state?

Thanks,
Sergii

[stanhu]

@syakovyn Thanks for raising your concerns here.

The service provider sends a state to the IdP and expects it back. I'm expecting the IdP to return the sent state back.

As discussed above, if we modified require_state NOT to send the state parameter in the first place, would this handle this case?

The IdP makes a direct request to the service provider without the state. No state check is expected here.

I'm a little confused about this case. In this case, the callback_phase is invoked directly from the IdP without authorize_uri? Perhaps a flow diagram would help.