Version 2.0.10 breaks Microsoft Oauth

[yknx4]

This is the code we use

    def client_id
      ENV["AZURE_APPLICATION_CLIENT_ID"]
    end

    def client_secret
      ENV["AZURE_APPLICATION_CLIENT_SECRET"]
    end

    def client
      @client ||= OAuth2::Client.new(
        client_id,
        client_secret,
        site:          "https://login.microsoftonline.com/",
        token_url:     "common/oauth2/v2.0/token",
        authorize_url: "common/oauth2/v2.0/authorize",
      )
    end

And this is the endpoint call that fails

openid_configuration = client.request(:get, "/common/v2.0/.well-known/openid-configuration")

Edit 10:48am:
This is innacurate, I found that it is a different code path that fails, running in debug mode I get this error instead

E, [2025-05-20T10:47:36.325610 #23904] ERROR -- omniauth: (microsoft_graph) Authentication failure! undefined method '+' for nil: NoMethodError, undefined method '+' for nil

In 2.0.9 it works perfectly fine, in 2.0.10 it returns this error

E, [2025-05-20T08:53:25.904180 #14849] ERROR -- omniauth: (microsoft_graph) Authentication failure! invalid_credentials: OAuth2::Error, invalid_client: AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '2420f2a9-XXXXX'. Trace ID: 9f152d9e-b7bf-4ff0-8987-e12ff63d5b01 Correlation ID: 61c457e0-e704-4037-8704-6ba5b138c59e Timestamp: 2025-05-20 15:53:25Z
{"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '2420f2a9-XXXXX'. Trace ID: 9f152d9e-b7bf-4ff0-8987-e12ff63d5b01 Correlation ID: 61c457e0-e704-4037-8704-6ba5b138c59e Timestamp: 2025-05-20 15:53:25Z","error_codes":[7000215],"timestamp":"2025-05-20 15:53:25Z","trace_id":"9f152d9e-b7bf-4ff0-8987-e12ff63d5b01","correlation_id":"61c457e0-e704-4037-8704-6ba5b138c59e","error_uri":"https://login.microsoftonline.com/error?code=7000215"}

[pboling]

Thanks for the report! I'll look into this shortly.

This gem does have 100% code coverage for lines and branches, and the bug should be reproducible in specs fairly easily, if you'd like to take a crack at it.

[yknx4]

@pboling I gave an inaccurate report before. The code that actually causes the issue when integrating with omniauth is the following one

 access_token.get(oidc_config['jwks_uri']).parsed[:keys]

In version 2.0.9 using symbol :keys did return the keys, but in 2.0.10 it returns nil, and you need to pass a string instead of a symbol.

2.0.10:

[8] pry(#<OmniAuth::MicrosoftGraph::DomainVerifier>)> access_token.get(oidc_config['jwks_uri']).parsed[:keys]
=> nil
2025-05-20 11:08:59.278375 W [38370:puma srv tp 004 mash.rb:404] {subdomain: www2} Rails -- You are setting a key that conflicts with a built-in method SnakyHash::StringKeyed#keys defined in Hash. This can cause unexpected behavior when accessing the key as a property. You can still access the key via the #[] method.
[9] pry(#<OmniAuth::MicrosoftGraph::DomainVerifier>)> 

with string key

[9] pry(#<OmniAuth::MicrosoftGraph::DomainVerifier>)> access_token.get(oidc_config['jwks_uri']).parsed["keys"]
2025-05-20 11:10:08.187895 W [38370:puma srv tp 004 mash.rb:404] {subdomain: www2} Rails -- You are setting a key that conflicts with a built-in method SnakyHash::StringKeyed#keys defined in Hash. This can cause unexpected behavior when accessing the key as a property. You can still access the key via the #[] method.
=> [{"kty" => "RSA",
  "use" => "sig",
  "kid" => "JYhSOsHhDZrc5kfqQg8ujkHMTNY",
  "x5t" => "JYhSOsHhDZrc5kfqQg8ujkHMTNY",
  ........
[10] pry(#<OmniAuth::MicrosoftGraph::DomainVerifier>)> 

So at some point there was a backwards incompatible change. I'm looking at the code to find where that happened.

[pboling]

Yep... good point. The change was to address issues raised around serialization. The Hash-like object that supported string key access was not serializable the way Hash is. So I changed the return type of parsed to be a standard Hash.

Perhaps the solution there is to make the "snaky" Hash serialize better (i.e. as a normal Hash).

[pboling]

That ^ would potentially be a change to the snaky_hash gem. https://gitlab.com/oauth-xx/snaky_hash, and would also certainly require changes to this gem to revert the return type.

[pboling]

@yknx4 This will fix it in a backwards compatible way. People who need to serialize will be able to, and people who need functionality as-is (in v2.0.9) can have that.
ruby-oauth/snaky_hash#2

Will have another PR to this repo to update to latest snaky_hash and document the new option for serializer, which will be turned off by default to preserve existing behavior.

I might break the serializer out into a separate gem, since it is based on https://github.com/krystal/serialized-hashie

[pboling]

This is the last part of the improvement to snaky_hash:
ruby-oauth/snaky_hash#3

[pboling]

🎉 I've just released snaky_hash v2.0.2. It handles hashes in oauth / oauth2 gems. The bug reports around serialization can now be solved. 💯% documented, 💯% test coverage, lines and branches.

Also, my daughter helped with code review, and found a typo!

https://github.com/oauth-xx/snaky_hash

And most importantly, now I can fix this issue.