nov / rack-oauth2 Goto Github PK

I have two questions.
Firstly, If the rack-oauth2 server supports the function which the third-party application can use to register to the service provider and then get the app key and app secret? I can find the function.

Secondly, what is OAuth2 server meaning? if it means service provider?

rack-oauth2 expects a response to be a hash and calls with_indifferent_access on it, but webmock doesn’t allow a hash for a response.

With a hash to agree with rack-oauth2, webmock complains:

Failures:

  1) Api doesn't agree on the return type
     Failure/Error:
       stub_request(:post, 'http://token-server.com/')
         .with(
           body: { 'grant_type' => 'client_credentials' },
           headers: {
             'Accept' => '*/*',
             'Accept-Encoding' => 'gzip;q=1.0,deflate;q=0.6,identity;q=0.3',
             'Authorization' => 'Basic bXkraWRlbnRpZmllcjpteStzZWNyZXQ=',
             'Content-Type' => 'application/x-www-form-urlencoded',
             'User-Agent' => 'Rack::OAuth2 (2.2.0)'
           }
     
     WebMock::Response::InvalidBody:
       must be one of: [Proc, IO, Pathname, String, Array]. 'Hash' given
     # ./spec.rb:19:in `block (2 levels) in <top (required)>'

Finished in 0.01229 seconds (files took 0.30281 seconds to load)
1 example, 1 failure

otherwise, to agree with Webmock and use a string:

Failures:

  1) Api doesn't agree on the return type
     Failure/Error: expect(subject.fetch!).to be_nil
     
     NoMethodError:
       undefined method `with_indifferent_access' for "{\"access_token\":\"token\"}":String
     
               token_hash = response.body.with_indifferent_access
                                         ^^^^^^^^^^^^^^^^^^^^^^^^
     # ./main.rb:8:in `fetch!'
     # ./spec.rb:23:in `block (2 levels) in <top (required)>'

Finished in 0.01771 seconds (files took 0.2967 seconds to load)
1 example, 1 failure

I've made a repo for you to check out the bug: https://github.com/freesteph/rack-oauth2-webmock-issue

In my hash that gets sent back to the client app, after first authorization is successful, is there a way to include the user's email and other information in that hash?

Any help would be great.

When i get the hash back, shouldn't there be a UID or something? If not what method do i change to add one?

provider: myname
uid:
credentials:
token: longasstokenhere9283sids2932==

I'm trying to understand how to implement scopes in my API app, but the server example app doesn't implement this.

In my TokenEndpoint, I'm checking the scope list against the scope the User/Client has access to and I'm calling req.invalid_scope! if the requested scope exceeds that of the User or Client. I'm not sure that invalid_scope is the correct error type in this case, the specification merely says invalid, malformed, unknown. Are you even supposed to check for User/Client scope in that endpoint? Or do you just write the scope to the access_token and then authorize when they actually try to use that access_token on some resource?

Also, in my controller/route, if the access_token's scope doesn't have access to the resource, how do raise a forbidden with the appropriate auth response errors? Do I call request.insufficient_scope!?

This gem is a lot more comprehensive than the README presents, but some more documentation and tutorials on how to use it would really be helpful. Thanks.

ex:
curl -v -XGET 'localhost:3000/me?oauth_token=VMhkQHqCeJ4IdMJaxF6SzQ=='

modifying attr_required would be the best solution.

• attr_optional! - make the attribute optional even if it's required
• undef & remove required attributes list
• any other?

The return url contains '#' instead '?'.

http://localhost:4567/skills#error=access_denied&error_description=The+end-user+or+authorization+server+denied+the+request.

I used a token for authorization.

For this kind of use-cases, we need multiple redirect_uri support.
#11

Issue

The gem rack-oauth2 has json-jwt >= 1.11.0 as dependency which is vulnerable to CVE-2023-51774 (see GHSA-c8v6-786g-vjx6).

Patched versions are 1.16.6 and 1.15.3.1.

Temporary fix

Add gem 'json-jwt', '>= 1.16.6' to your gemfile to ensure the patched gem version.

Is it possible to set a access token to never expire so clients never have to reauth? Is this frowned upon in the oauth2 flow?

I've heard a lot about this gem but the documentation is dismal. I think the README should be a little more descriptive and help people start off implementing an OAuth 2.0 endpoint in Rack

The OAuth 2.0 standard, in section 2.3.1 on client authentication using a client password, says the following:

The client identifier is encoded using the
"application/x-www-form-urlencoded" encoding algorithm per
Appendix B, and the encoded value is used as the username; the client
password is encoded using the same algorithm and used as the
password.

We ran into this problem when integrating with an OpenID Connect provider which only allows fully qualified urls as client_id (eg. "https://www.example.com").
With the current code in lib/rack/oauth2/client.rb we get this example:

identifier = 'https://www.example.com'
secret = 'supersecret'
cred = ["#{identifier}:#{secret}"].pack('m').tr("\n", '')
# => "aHR0cHM6Ly93d3cuZXhhbXBsZS5jb206c3VwZXJzZWNyZXQ="

While from the standard one might expect:

cred = ["#{CGI.escape(identifier)}:#{CGI.escape(secret)}"].pack('m').tr("\n", '')
# => "aHR0cHMlM0ElMkYlMkZ3d3cuZXhhbXBsZS5jb206c3VwZXJzZWNyZXQ="

This comment in a Github issue for another project does a better job of explaining the ambiguity of the spec than I could.

Of course, using a colon in the identifier, when rfc2617 explicitly forbids this, doesn't seem like the best idea from our provider. There are however other characters that would also be escaped by this, like the '!' used in the example in the issue above.

I would be happy to provide a pull request with the code for this, if you feel like this is a issue you would like to address. If this is deemed a breaking change, we could maybe include this as a separate explicit :client_auth_method?

@nov plz, update patch in VERSION file and upload gem 📦 to rubygems. I use this gem in production, and i wish specify new version of gem instead of my branch :)

Pleeeeeeeease 😋

We're using rack-oauth2 as the basis for our Oauth and OIDC server. Recently we were prototyping an identity bridge project using Keycloak. It was configured to use private_key_jwt client authentication and would encounter a 400 during the code exchange for the identity and access tokens. Through some debugging I determined that Keycloak does not send the client_id param when using private_key_jwt client authentication, but rack-oauth2 requires it. I thought this was a bug in Keycloak but then I reviewed the RFCs and discovered that it is in fact optional to send the client_id param. Below I provide links to the RFCs, and potential solutions to this problem in rack-oauth2.

Per https://www.rfc-editor.org/rfc/rfc7523.html#section-2.2, a token request can be of grant type, authorization_code, and still use JWT bearer for authentication by specifying the client_assertion_type and client_assertion params. Moreover, per https://www.rfc-editor.org/rfc/rfc7521.html#section-4.2, which is the base RFC that RFC7523 extends, the client_id is optional in JWT bearer token requests.

However, the server token code is written in a way that will not allow this scenario to occur. This is because it uses the grant_type_for method to determine which grant type class to use, and the JWT bearer grant type is only used for authorization requests, not token requests. Moreover, the AuthorizationCode grant type class inherits from TokenRequest class, which inherits from AbstractRequest, and AbstractRequest requires the client_id param. Neither the TokenRequest or the AuthorizationCodeRequest classes override the requirement, whereas the JWTBearer class does. The same is true for the ClientCredentials token request class. Consequently, client_id is required even though the spec states that it is optional for client authentication when using a client assertion token.

I've been trying to think of how to fix the code to accommodate this behavior, but because attr_required/attr_optional are evaluated during the class load, I'm not sure what the best way to move forward is.

My first thought would be when the token request class is initialized, the params are checked for the client_assertion param, and if present, the client_id param would be optional. But again, the macros are evaluated at class load, so that's not really possible unless we modify attr_required to take a proc in order to evaluate an if/unless condition at the instance level.

So my next thought is to make the client_id param optional, and then append client_id to the required_attributes array during initialization if the client_assertion param is missing. However, this option feels very much like a hack.

The last option that I can think of is to just make the client_id param always optional. On the one hand this option actually seems best, since the best current security practice is to use private_key_jwt auth instead of a shared secret. However, on the other hand, I know that using a shared secret is still very common practice, and this library tries to build in the behavior that the protocol (in all its forms) requires.

I'm happy to address this issue but I'm not sure what the best way forward is. I welcome any guidance.

When using the OAuth2 client with a resource owner password grant towards Azure AD, a resource has to be specified as outlined here:

AADSTS90014: The request body must contain the following parameter: 'resource'.

It would be great if OAuth2::Client.access_token! would accept additional params as an option. Will open a PR as soon as I know whether this is the right place.

Hi,

As mentioned, of course, rack update to 2.1.1 breaks rack-oauth2 with the following test failures:

Failures:

  1) Rack::OAuth2::Server::Resource::BadRequest#finish should respond in JSON
     Failure/Error: response.body.should == ['{"error":"invalid_request"}']

     NoMethodError:
       undefined method `body' for ["{\"error\":\"invalid_request\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:13:in `block (3 levels) in <top (required)>'

  2) Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish should respond in JSON
     Failure/Error: response.body.should == ['{"error":"invalid_token"}']

     NoMethodError:
       undefined method `body' for ["{\"error\":\"invalid_token\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:47:in `block (4 levels) in <top (required)>'

  3) Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when error_code is not invalid_token should have error_code in body but not in WWW-Authenticate header
     Failure/Error: response.body.first.should include '"error":"something"'

     NoMethodError:
       undefined method `body' for ["{\"error\":\"something\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:56:in `block (5 levels) in <top (required)>'

  4) Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when no error_code is given should have error_code in body but not in WWW-Authenticate header
     Failure/Error: response.body.first.should == '{"error":"unauthorized"}'

     NoMethodError:
       undefined method `body' for ["{\"error\":\"unauthorized\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:66:in `block (5 levels) in <top (required)>'

  5) Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when realm is specified should use given realm
     Failure/Error: response.body.first.should include '"error":"something"'

     NoMethodError:
       undefined method `body' for ["{\"error\":\"something\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:77:in `block (5 levels) in <top (required)>'

  6) Rack::OAuth2::Server::Resource::Forbidden#finish should respond in JSON
     Failure/Error: response.body.should == ['{"error":"insufficient_scope"}']

     NoMethodError:
       undefined method `body' for ["{\"error\":\"insufficient_scope\"}"]:Array
     # ./spec/rack/oauth2/server/resource/error_spec.rb:94:in `block (3 levels) in <top (required)>'

  7) Rack::OAuth2::Server::Resource::Forbidden when scope option is given should have blank WWW-Authenticate header
     Failure/Error: response.body.first.should include '"scope":"scope1 scope2"'

     NoMethodError:
       undefined method `body' for #<Array:0x00005580a289cb28>
     # ./spec/rack/oauth2/server/resource/error_spec.rb:103:in `block (3 levels) in <top (required)>'

  8) Rack::OAuth2::Server::Token::BadRequest#finish should respond in JSON
     Failure/Error: response.body.should == ['{"error":"invalid_request"}']

     NoMethodError:
       undefined method `body' for ["{\"error\":\"invalid_request\"}"]:Array
     # ./spec/rack/oauth2/server/token/error_spec.rb:13:in `block (3 levels) in <top (required)>'

  9) Rack::OAuth2::Server::Token::Unauthorized#finish should respond in JSON
     Failure/Error: response.body.should == ['{"error":"invalid_request"}']

     NoMethodError:
       undefined method `body' for ["{\"error\":\"invalid_request\"}"]:Array
     # ./spec/rack/oauth2/server/token/error_spec.rb:29:in `block (3 levels) in <top (required)>'

  10) Rack::OAuth2::Server::Token when multiple client credentials are given when different credentials are given should fail with unsupported_grant_type
      Failure/Error: response.body.first.should include '"error":"invalid_request"'

      NoMethodError:
        undefined method `body' for #<Array:0x00005580a1f30f08>
      # ./spec/rack/oauth2/server/token_spec.rb:33:in `block (4 levels) in <top (required)>'

Finished in 0.76006 seconds (files took 2.76 seconds to load)
374 examples, 10 failures

Failed examples:

rspec ./spec/rack/oauth2/server/resource/error_spec.rb:9 # Rack::OAuth2::Server::Resource::BadRequest#finish should respond in JSON
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:42 # Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish should respond in JSON
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:53 # Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when error_code is not invalid_token should have error_code in body but not in WWW-Authenticate header
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:63 # Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when no error_code is given should have error_code in body but not in WWW-Authenticate header
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:74 # Rack::OAuth2::Server::Resource::Unauthorized when scheme is defined #finish when realm is specified should use given realm
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:90 # Rack::OAuth2::Server::Resource::Forbidden#finish should respond in JSON
rspec ./spec/rack/oauth2/server/resource/error_spec.rb:101 # Rack::OAuth2::Server::Resource::Forbidden when scope option is given should have blank WWW-Authenticate header
rspec ./spec/rack/oauth2/server/token/error_spec.rb:9 # Rack::OAuth2::Server::Token::BadRequest#finish should respond in JSON
rspec ./spec/rack/oauth2/server/token/error_spec.rb:24 # Rack::OAuth2::Server::Token::Unauthorized#finish should respond in JSON
rspec ./spec/rack/oauth2/server/token_spec.rb:30 # Rack::OAuth2::Server::Token when multiple client credentials are given when different credentials are given should fail with unsupported_grant_type

Any idea how to fix this?

try with response_type=unknown for reproducing it.

Hi nov, I'm a newbie who's looking for a library to let a Rails App becomes a OAuth 2 provider and I arrived here. This library looks good but could you give some instructions beyond the installation? For example, I'd like to know what should I do after I add the gem 'rack-oauth2' in the Gemfile and run bundle install :-)

I'm a Chinese and if you feel confused by my poor English, just tell me. Thank you~

I just noticed in rack-oauth2/lib/rack/oauth2/urn.rb the token value:

        ACCESS_TOKEN  = 'urn:ietf:params:oauth:token-type:access-token'  # draft-ietf-oauth-token-exchange

is incorrect, according to the spec it should be (notice the underscore vs dash):

urn:ietf:params:oauth:token-type:access_token

Reference: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#section-7.1.1

Your gem is lightweight rack-middleware bundle. But you have very heavy dependency - ActiveSupport

Commonly you use active_support/core_ext
The best solution is use gem facets. Coz it's lightweight too.

What do you think about it?

Hello,

README states that this gem is based on draft 15.
Isn't it based on draft 16?

Take a look on how the access request header looks on draft 15:
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC token="h480djs93hd8",
timestamp="137131200",
nonce="dj83hs9s",
signature="kDZvddkndxvhGRXZhvuDjEWhGeE="

And now on draft 16:
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

And the code: https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/access_token/mac.rb#L67

Have I missed something?

Thank you :) Great gem! Hope to make contributions soon.

Hi.

Are there any immediate plans to support extension / assertion grants?

What we are looking to accomplish is trading an access token generated by a user signing in via a 3rd party provider (such as Facebook), then trading that token (after verification on our end) for an access token from rack-oauth2. (Just to be clear, this process occurs via a native mobile app).

Is there perhaps another known workaround for this case when extension/assert is unavailable?

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

  spec.license = 'MIT'
  # or
  spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Similar to nov/fb_graph2#102

DEPRECATION WARNING: alias_method_chain is deprecated. Please, use Module#prepend instead. From module, you can access the original method using super. (called from <class:Request> at /.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-oauth2-1.2.1/lib/rack/oauth2/server/abstract/request.rb:24)

I'm working on a project that is going to authenticate via openid_connect against login.gov (US government IDP). For development, they provide a sandbox that is (mildly) protected via basic auth: https://idp.int.login.gov/ To hit their authorization endpoint, one must provide a previously registered client_id (see https://developers.login.gov/oidc/#authorization).

In lib/rack/oauth2/client.rb:23, the client_id is being overridden and set to self.identifier. Later, on line 84, the same identifier is being used as the basic auth username. As such we are unable to successfully use the IDP with any configuration.

We can get around this by simply commenting out line 23 and passing client_id as a param, and setting the client's identifier to the basic auth username.

Why is the identifier being used for both, seemingly different, purposes? Commenting out the client_id override, all specs still pass so it's not clear why that is desired/required.

Any assistance/guidance you can provide would be greatly appreciated!

The README link points to https://rack-oauth2-sample.heroku.com/ which is broken. If I replace it with https://rack-oauth2-sample.herokuapp.com/, it raises an Application Error

As per this section of RFC6749, redirect_uri should be verified during token exchange

Do you follow Semantic Versioning as defined by semver.org? If yes, can you mention it in README, if not, can you consider it?

Currently only bearer, mac or nil are supported as :token_type. It would be awesome to have support for custom values.

If we take Ebay for example, it mints 2 types of tokens: Application Access Token and User Access Token, which are set inside the :token_type in corresponding successful response.

As both of them are of basically Bearer token types, we can simply add the regexp in the Rack::OAuth2::Client#handle_success_response method on line #148 to support the case:

when /bearer|access token/

Do you think it should work?

Many Thanks!

I've just removed ActiveSupport usage from rack-oauth2. Whether you are interested to merge it?

For proofs:

• less memory footprint
• no monkey patching and hidden surprises
• less dependencies

Last item is doubtful, because I added a two small dependencies for backward compatibility with removed functionality.

In our fb_graph app, when we upgraded from rack-oauth2 0.14.2 to 0.14.4, all Facebook requests would fail with an uncaught 400 exception.

The failures were coming from trying to auth via cookies:

    fb_auth = FbGraph::Auth.new(FACEBOOK_APP_ID, FACEBOOK_APP_SECRET)
    fb_auth.client # => Rack::OAuth2::Client

    fb_auth.from_cookie(cookies)

Any known changes that would be causing this? Reverting back to 0.14.2 fixed the problem.

would be great to keep track of big changes and breaking changes, if any. Thanks.

Is https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/server/authorize.rb#L49 actually used anywhere outside the specs?

I was updating an older app and found that I could not update beyond version 1.12 due to the requirement for rack >2.1.0. This breaks code that is based on the example code in https://github.com/nov/rack-oauth2-sample. Specifically, it breaks in code based on app/controllers/authorizations_controller.rb:

def respond(status, header, response)
  ["WWW-Authenticate"].each do |key|
    headers[key] = header[key] if header[key].present?
  end
  if response.redirect?
    redirect_to header['Location']
  else
    render :new
  end
end

With:

NoMethodError: undefined method 'redirect?' for []:Array

I see that fixes have been made to the tests in 1.13.0.beta to account for the change in the return value from rack, but the sample code has not been updated to work with that version.

From what I can tell, we now get less information since we don't actually get the response object anymore. What is the best way to rewrite this method so that it works as before?

If i want use Rack::OAuth2::Server::Token as Middleware in my application, i can't do this, coz its constructor have no app argument.

module Rack
  module OAuth2
    module Server
      class Token < Abstract::Handler
        # ...
      end
    end
  end
end

# Abstract::Handler class looks like this

module Rack
  module OAuth2
    module Server
      module Abstract
        class Handler
          attr_accessor :authenticator, :request, :response

          def initialize(&authenticator)
            @authenticator = authenticator
          end
        end
      end
    end
  end
end

If we lookup at Rack implementation of AbstractHandler we see something like this

module Rack
  module Auth
    class AbstractHandler
      attr_accessor :realm

      def initialize(app, realm=nil, &authenticator)
        @app, @realm, @authenticator = app, realm, authenticator
      end
    end
  end
end

So, in my Sinatra app, i can use Native Rack like this

use Rack::Auth::AbstractHandler, "MyHadnler", do
  # ...
end

But, when we talk about your handler, i cant use it so simple way 😢

Of Course, i can write my implementation of your Abstract::Handler and redefine initialize method, but that's not clear and correct

According to https://datatracker.ietf.org/doc/html/rfc6749#section-4.3.2, Access Token Request doesn't require client_id for grant_type="password", not even optional, however

made client_id mandatory, and Rack::OAuth2::Server::Token::Password raises AttrRequired::AttrMissing error on call, and end-user sees

{
    "error": "invalid_request",
    "error_description": "'client_id' required."
}

if client_id is not provided.

Maybe attr_required :client_id should be moved to other Token endpoint handlers where required?

I was wondering if you would be interested in a PR to add PKCE support for Authorization Code Grants?

It's being adopted wider now, although it's possible to use with this library it'd be great if it was a first class citizen.

instead of explicitly using to_json calls, use the multi-json gem so that host appilcations can choose their json encoder.

ex: I use yajl for all of my applications due to the drastic performance improvements compared to the basic to_json library.

I've been using cyu/rack-cors to provide access my API through XHR requests. This returns the following headers:

Access-Control-Allow-Credentials:true
Access-Control-Allow-Methods:GET, PUT, CREATE, DELETE
Access-Control-Allow-Origin:http://app.mydomain.dev
Access-Control-Expose-Headers:
Access-Control-Max-Age:1728000

However, when I want to start using Rack-OAuth2, wrapped in the socialcast/devise_oauth2_providable gem for Rails/Devise, things go wrong.

When I start authenticating the backend using devise_oauth2_providable with :authenticate_user!, the CORS headers are lost and I can no longer access my API:

XMLHttpRequest cannot load http://api.mydomain.dev/projects.
Origin http://app.mydomain.dev is not allowed by Access-Control-Allow-Origin.

(no response-header is returned and the request simply stops with Status showing as canceled)

Could it be that Rack-OAuth2 overrides all previous set headers and therefor the cors headers are no longer sent back? And if so, does anyone know a solution to this?

I've also created a ticket at socialcast/devise_oauth2_providable#40, but I doubt that gem has anything to do with this, it seems more likely that the problem originates from here.

I am trying to build rack-oauth2 for Debian and I am getting the following error.

Failures:

  1) Rack::OAuth2::Client#access_token! *args handling client authentication method when jwt_bearer auth method specified when private_key is given when EC key should be JWT bearer client assertion w/ auto-generated ES256-signed JWT assertion
     Failure/Error: private_key: OpenSSL::PKey::EC.new('prime256v1').generate_key,
     
     OpenSSL::PKey::PKeyError:
       pkeys are immutable on OpenSSL 3.0
     # ./spec/rack/oauth2/client_spec.rb:191:in `generate_key!'
     # ./spec/rack/oauth2/client_spec.rb:191:in `block (8 levels) in <top (required)>'
     # ./spec/rack/oauth2/client_spec.rb:89:in `block (5 levels) in <top (required)>'

Finished in 0.73756 seconds (files took 1.19 seconds to load)
403 examples, 1 failure

Failed examples:

rspec ./spec/rack/oauth2/client_spec.rb:197 # Rack::OAuth2::Client#access_token! *args handling client authentication method when jwt_bearer auth method specified when private_key is given when EC key should be JWT bearer client assertion w/ auto-generated ES256-signed JWT assertion  

Please help in resolving.

I'm integrating with an API that requires a custom header when requesting an Access Token (the client_id and client_secret params aren't enough for them, I guess). At present I don't see any way to accomplish this, but support could be added with a simple patch.

Something like the following in Rack::OAuth2::Client#access_token!:

I'm happy to work on it, but wanted to ask if that was potentially acceptable, or if I'm missing an existing way to do it, before spending time on it.

Could you please replace ActiveSupport::SecureRandom with SecureRandom on this line: https://github.com/nov/rack-oauth2/blob/master/lib/rack/oauth2/access_token/mac.rb#L79? This is just to prevent the deprecation message (DEPRECATION WARNING: ActiveSupport::SecureRandom is deprecated! Use SecureRandom instead.) showing up again and again.

shouldn't the libraries throw an exception if the request isn't coming in as https? Except perhaps in a development and/or test environment?

if you agree, I'll submit a patch.

thanks for the fantastic library,
adam

Hey guys,

Every time i try to do an implicit flow i get the access token with an hashtag (#) in the redirect_uri:
http://my.com/auth_callback#access_token=123abc

This is becuase the method protocol_params_location in the class Rack::OAuth2::Server::Authorize::Token::Response returns :fragment. Changing it to :query fixes the problem and returns the token as a http query parameter (with a questionmark):
http://my.com/auth_callback?access_token=123abc

I believe this to be a bug, am i correct in assuming this? If so I'm willing to make an PR.

Rack:OAuth2 version: 1.4
Rails version: 4.2.7
Ruby version: 2.3.1

Thank you so much for this gem! We are using it to connect to QuickBooks Online.

I need to be able to access the headers that come back as part of the requests I'm making. I see this information in the logs but it doesn't seem to be available in any way.

I would like to avoid doing non-thread safe things in Faraday. Is there any other way to access the response headers?