doorkeeper-gem / doorkeeper-openid_connect Goto Github PK

I noticed that native_oauth_authorization_path( /oauth/authorize/native ) returns the error :

undefined method `application' for nil:NilClass

at here.
This occurs only with doorkeeper 5.0.

--
Probably caused by this changes.
doorkeeper-gem/doorkeeper@698fba0

Steps to reproduce

• Create an application
• User authorizes application
• Go to doorkeeper admin page and delete application

Expected behavior

Able to delete application

Actual behavior

Unable to delete application:

Mysql2::Error - Cannot delete or update a parent row: a foreign key constraint fails (sample_app.oauth_openid_requests, CONSTRAINT fk_rails_77114b3b09 FOREIGN KEY (access_grant_id) REFERENCES oauth_access_grants (id)):

Reason

There are two problems.
First the problems above about Mysql, on doorkeeper-openid-connect table migration, I found that foreign key is added:

It's off-topic but I'm not understand the purpose to use foreign key, as all the validation can be done on Rails.

There are associations between:

• Doorkeeper::Application
• Doorkeeper::OpenidConnect::AccessGrant
• Doorkeeper::OpenidConnect::Request

Delete Application will delete AccessGrant and delete Request. However due to foreign key, AccessGrant can't be delete without delete associated Request first.

That's one problems, we can solve that by deleting foreign key in templates/migration.rb.erb, for existing application we can use migration:

def up
  remove_foreign_key :oauth_openid_requests, :oauth_access_grants
end

def down
  add_foreign_key(
      :oauth_openid_requests,
      :oauth_access_grants,
      column: :access_grant_id
  )
end

No error occurs. However, another problem is that associated openid_request are not deleted. To get to the reason, first let's see the model association:

Doorkeeper::Application
https://github.com/doorkeeper-gem/doorkeeper/blob/45b6ce568523a5e2f2cdc9c3ed60254d7891f8dc/lib/doorkeeper/orm/active_record/application.rb#L3-L11

class Doorkeeper::Application
    has_many :access_grants, dependent: :delete_all, class_name: "Doorkeeper::AccessGrant"
    has_many :access_tokens, dependent: :delete_all, class_name: "Doorkeeper::AccessToken"
end

Doorkeeper::OpenidConnect::AccessGrant

To recap:

Application has_many :access_grants, dependent: :delete_all
AccessGrant has_one :openid_request, dependent: :delete

When application is deleted, access_grants also are deleted, then openid_request should be deleted as well. However, because we are using dependent: :delete_all in Doorkeeper::Application so callback stop after delete :access_grants. If I change to dependent: :destroy, both :access_grants and :openid_request are deleted.

Rubymine tries to execute the following command:

/bin/zsh -c "bash -c '/Users/mark/.rvm/bin/rvm ruby-2.4.2 do /Users/mark/Dev/b2bwave/bin/bundle exec /Users/mark/.rvm/rubies/ruby-2.4.2/bin/ruby -Itest /Users/mark/Dev/b2bwave/test/controllers/api_customer/orders_controller_test.rb'"

This results in:

/Users/mark/.rvm/scripts/set: line 19: /Users/mark/Dev/b2bwave/bin/bundle: Permission denied
/Users/mark/.rvm/scripts/set: line 19: exec: /Users/mark/Dev/b2bwave/bin/bundle: cannot execute: Undefined error: 0

I have never encountered permissions issues with rvm on multiple installations.

Please advise.

Mark

If I have previously authorized with a Doorkeeper-OIDC-based IDP using scope=openid+email+name, a prompt=none authorization request with a more narrow set of claims, such as scope=openid+email will fail. The error will indicate that user consent is required, however I think this is incorrect. The user has already granted consent for the email and name claims; my reauthorization request is only requesting the email claim, so I believe the correct behavior is to generate and return a new access token with the openid and email claims.

If this is in fact a bug, the problem seems to be that an exact match between the incoming scopes and previously granted access token's scopes is required by this method:

# lib/doorkeeper/openid_connect/helpers/controller.rb

# ....
def handle_prompt_param!(owner)
# ...
  prompt_values.each do |prompt|
    case prompt
    when 'none' then
      # ...
      raise Errors::ConsentRequired unless matching_tokens_for_resource_owner(owner).present?

# ...

def matching_tokens_for_resource_owner(owner)
  Doorkeeper::AccessToken.authorized_tokens_for(pre_auth.client.id, owner.id).select do |token|
    Doorkeeper::AccessToken.scopes_match?(token.scopes, pre_auth.scopes, pre_auth.client.scopes)
  end
end

https://github.com/doorkeeper-gem/doorkeeper-openid_connect/blob/master/lib/doorkeeper/openid_connect/helpers/controller.rb#L79

Dependabot can't resolve your Ruby dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

Bundler::VersionConflict with message: Bundler found conflicting requirements for the Ruby version:
  In Gemfile:
    Ruby (~> 2.4.10.0)

    rails (~> 6.0.0) was resolved to 6.0.3.6, which depends on
      Ruby (>= 2.5.0)

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

I'm increasingly neglecting this gem because I'm not really using it in any of my current projects, and working with OAuth / OIDC is just generally causing me a lot of headaches 😛

If anybody wants to become a maintainer, please let me know!

/cc @nashby @nbulaj

As per doorkeeper-gem/doorkeeper#296, client_id is optional for the password grant type, however doorkeeper-openid_connect seems to assume that it will always be there.

Or thoughts?

Kinda see where this ties together and it looks like it's maybe complete enough to use or work from... any notes for someone who wants to use this?

The offline_access scope defined in the OIDC specification appears to be completely unsupported as yet.

So as to not break peoples' existing oidc flows it would probably be prudent to put this in behind a config option.

I think for the application I'm working on it's not security-critical to have this feature, but if I find out otherwise I'll likely end up implementing it in Q1 / Q2 2021.

I'm looking into implementing OpenID Connect in GitLab and stumbled over this gem, as well as the lower-level openid_connect Rack middleware. As GitLab already uses Doorkeeper this approach seems a lot more straight-forward, so I'm planning to first improve this gem a bit and have a few questions:

• What's the current status and your future plans, which areas need the most love?
• Do you have an overview of which parts of the core spec are implemented?
• Have you tried the conformance testing with this library?

Thanks for your work!

Doorkeeper version: 5.2.1
doorkeeper-openid_connect version: 1.7.0

It seems that when Doorkeeper introduced Strong Parameters in the app/controllers/doorkeeper/authorizations_controller.rb the nonce parameter has been filtered out and therefore lib/doorkeeper/openid_connect/oauth/authorization/code.rb doesn't store it.

This causes the nonce not to be present in the ID Token as the spec requires, and OIDC clients that validate nonces crash.

The Doorkeeper::AuthorizationsController checks to see whether or not required parameters are present by running pre_auth.authorizable? in the new action.

This gem modifies the behavior of the :authenticate_resource_owner! before filter that runs prior to the new action. One of the modifications is to inspect the pre_auth object (an instance of OAuth::PreAuthorization) and look at its scopes.

The OAuth::PreAuthorization#scopes method in turn fires the build_scopes private method, which calls client.application.scopes. This method assumes that client is present. However, if you do not initialize the object with @client, it obviously blows up. This has not been an issue in Doorkeeper itself, because usually the OAuth::PreAuthorization object is assumed to be valid. However, this OpenID Connect gem inspects the object before it has been validated.

We have a PR to add a validation check before trying to inspect the scopes.

How can I implement openid with password grant type?

Hello, this isn't an issue per se, it's more of an integration question.

We're interested in using this along with our web sessions to authenticate a user against our Devise framework (which, of course, uses Warden in the background). Our team has some experience with oAuth and other authentication protocols, but none in particular with OpenID Connect and rails app integration.

The main questions are:

1. Is something like the warden-doorkeeper gem the best solution to begin integrating these, or can it be more simply done?
2. Is it possible to use existing session state if the user is already logged in?
3. Which part of this is responsible for rendering the view wherein the user (post-authentication) is presented with the requested scopes/claims and accepts or rejects the authorization request?

Finally, is a migration on the user to store some sort of subject identifier required or is there a property on the user object provided by doorkeeper already that can be coopted into this role?

Thank you very much!

Problem

With prompt=login, we have the reauthenticate_oidc_resource_owner method to call the config reauthenticate_resource_owner. So user just have to defined some code in reauthenticate_resource_owner in doorkeeper_openid_connect.rb to execute the code as user's need.

Why doorkeeper oidc don't have the equivalent config when prompt=select_account?
https://github.com/doorkeeper-gem/doorkeeper-openid_connect/blob/master/lib/doorkeeper/openid_connect/helpers/controller.rb#L68-L71
If possible could we add config function for select_account?

Currently behavior

Because the gem only write that:

when 'select_account'
  # TODO: let the user implement this
  raise Errors::AccountSelectionRequired

the error is rescued at here. So to be able to use prompt=select_account, I see that user have to monkey-patch the handle_oidc_prompt_param! method as following:

def handle_oidc_prompt_param!(owner)
  super(owner)
rescue Errors::AccountSelectionRequired
  # user's defined select_account behavior  
end

that not clean, hard to maintain for user.

Expect

when 'select_account'
  call_select_account_config(owner) # execute the config for select_account

What do you think about this idea?

From the spec at https://openid.net/specs/openid-connect-discovery-1_0.html:

grant_types_supported

OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the authorization_code and implicit Grant Type values and MAY support other Grant Types. If omitted, the default value is ["authorization_code", "implicit"].

This should be added to app/controllers/doorkeeper/openid_connect/discovery_controller.rb, and return the appropriate values based on the current Doorkeeper configuration.

Current version of json-jwt gem supports Ruby >= 2.3 https://github.com/nov/json-jwt/blob/master/json-jwt.gemspec#L14. That's the reason why Travis is failing with older rubies. There's two options: 1. lock json-jwt version that supports older rubies 2. drop support for Ruby < 2.3.

@toupeira what do you think?

Hello,

I am a bit confused about the signing key.

I understand that only the private key needs to be provided in the config because the public key can be generated from the private one.

However shouldn't the public key be provided to the client application so that it can verify the JWS signature?

Additionally, if we are not using the implicit flow that returns the id_token (e.g. we use the authorization code flow only), we can skip this configuration, correct?

Turns out the gem requires the signing_key even if no id_token is being requested.

TIA

When I visit '/oauth/userinfo', the program returns an error:

#<AbstractController::ActionNotFound: The action 'show' could not be found for Doorkeeper::OpenidConnect::UserinfoController>

api_only: true

The view generated by the command rails generate doorkeeper:views of the doorkeeper gem does not contain a nonce. So even if I add a nonce parameter to Authentication Request, nonce does not include in the issued ID token.

Of course I understand that I can solve the problem by adding hidden_field_tag nonce to view, but I think it is difficult to notice this problem.

refs:
https://github.com/doorkeeper-gem/doorkeeper/blob/adea1d22cd1040b7d62bd35974e4fab0e588910f/app/views/doorkeeper/authorizations/new.html.erb#L22-L43

Some flows shouldn't have an id_token associated with them. See client credentials flow

id_token is nil in this flow so when it's injected it fails. Will fix today.

User-Agent: Faraday v0.8.9
Content-Type: application/x-www-form-urlencoded
Accept: */*
Connection: close
Host: auth.bluebox.dev:3000
Content-Length: 201


grant_type=client_credentials&client_id=3cc8660497742aef17175af7ef9676523bd01df68b6292d679771ad478e17bd9&client_secret=1e09cbd831c461b65be729bddffd2d0b21d5756b43f14b69eda59e975b8a1c87&scope=application
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain; charset=utf-8
X-Request-Id: 1c3f405d-c7c2-4975-ace7-d1e5dc8da87f
X-Runtime: 0.343117
Connection: close
Server: thin 1.6.2 codename Doc Brown


NoMethodError at /oauth/token
=============================

> undefined method `as_jws_token' for nil:NilClass

 () home/nifty/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bundler/gems/doorkeeper-openid_connect-da800934af64/lib/doorkeeper/openid_connect.rb, line 56
------------------------------------------------------------------------------------------------------------------------------------------------------

   51         attr_accessor :id_token
   52         alias_method :original_body, :body
   53   
   54         def body
   55           original_body.
>  56             merge({:id_token => id_token.as_jws_token}).
   57             reject { |_, value| value.blank? }
   58         end
   59       end
   60     end
   61   end

This repository seems abandoned for a long time, hope to give some new solution.

tl;dr Doorkeeper OIDC can be provoked to blindly redirect the browser to whatever site is sent in redirect_uri paramter when prompt=none.

Given an otherwise valid authorization attempt with prompt=none, if an error can be provoked, the user is redirected to whatever redirect URI is passed in through the redirect_uri parameter with an error message in the query string.

For example, assume I have a Doorkeeper-backed Identity provider at identity-provider.com. It has an application with a client ID of 123 and a redirect-URI of https://real-site.com/callback.

If I have previously authorized with identity-provider.com with the openid profile claims, and I issue a new authorization request with only the openid scope, and prompt=none, an error is raised because the claims I'm requesting don't match the claims I previously authorized, but prompt=none prevents me from reauthorizing.

The error causes me to be redirected to whatever redirect_uri is included in the request, even if it's not a valid whitelisted redirect URI for the subject application.

A sample request, assuming I'm already authorized (newlines added for clarity):

https://identity-provider.com/oauth/authorize?
  client_id=123
  redirect_uri=https%3A%2F%2Fattacksite.com&
  response_type=code&
  scope=openid&
  prompt=none

This request sends me to (again, newlines added for clarity):

https://attacksite.com/?
  error=consent_required&
  error_description=The+authorization+server+requires+end-user+consent

At this point, attacksite.com can display a phishing form; given that I clicked on a link that started with identity-provider.com to start the authorization flow, it's possible that I can be tricked into entering my credentials into the attacking site. This is (I believe) an example of a Dangerous URL Redirect.

The problem seems to be in how exceptions are rescued:

https://github.com/meagar/doorkeeper-openid_connect/blob/12685b19af46e0e1abcf6c74efe919268fec34f8/lib/doorkeeper/openid_connect/helpers/controller.rb#L22

error = ::Doorkeeper::OAuth::ErrorResponse.new(
  name: exception.error_name,
  state: params[:state],
  redirect_uri: params[:redirect_uri])

This line extracts redirect_uri directly from the incoming parameters, and does nothing to validate it before redirecting the browser there on subsequent lines.

I think the correct behaviour here is to render a 422 error, rather than redirect the browser, regardless of the prompt=none.

Why does IdToken not incorporate user defined claims? Is it because you want to minimize the token size? Perhaps it should respect the scope parameter and incorporate user defined claims if a certain scope value (e.g. profile) is present in the scope?

It should require explicit consent to issue new code, but shouldn't revoke any other access and/or refresh tokens which are issued at different timing.
https://github.com/doorkeeper-gem/doorkeeper-openid_connect/blob/master/lib/doorkeeper/openid_connect/helpers/controller.rb#L44

My payload contains this:

"grant_types_supported": [
"authorization_code",
"refresh_token",
"refresh_token",
"refresh_token",
"refresh_token",
... etc (over 30 refresh_token duplicates in the array)

Edit to add more information: I have not yet been able to reproduce the bug locally, but on my heroku deployment, a duplicate entry is added to the array every time the page is refreshed. Restarting the dynos resets it. 🤔

It is my understanding that if the response type is form_post the OP will POST the response instead of encoding the id_token (etc) in the query string or fragment.

I can't find evidence of it being supported by looking at the source code.

Please advise, TIA.

Hi!

Is there any reason why this gem uses json-jwt gem dependency instead of jwt gem?
The jwt gem is more complete and has a big community (jwt.io). For example gem doorkeeper-jwt uses gem jwt.

The problem was fixed but the version was not upped. The latest version in rubygems.org is 1.0.0 which does not have the fix.

According to the JWT spec:

The "kid" (key ID) header parameter is a hint indicating which specific key owned by the signer should be used to validate the signature. This allows signers to explicitly signal a change of key to recipients. Omitting this parameter is equivalent to setting it to an empty string. The interpretation of the contents of the "kid" parameter is unspecified. This header parameter is OPTIONAL.

I don't think setting it to the public key is the right thing to do. Specifically, to be interoperable with mod_auth_openidc it would be better to leave out the kid parameter.

Is there some plan to support the openid connect flow like client credentials?

Are there any plans to support RP initiated logout as per the Spec?

https://openid.net/specs/openid-connect-session-1_0.html#RPLogout

Thanks!

The migration currently generated by the gem itself looks like this :
lib/generators/doorkeeper/openid_connect/templates/migration.rb.erb

class CreateDoorkeeperOpenidConnectTables < ActiveRecord::Migration<%= migration_version %>
  def change
    create_table :oauth_openid_requests do |t|
      t.integer :access_grant_id, null: false
      t.string :nonce, null: false
    end

    add_foreign_key(
      :oauth_openid_requests,
      :oauth_access_grants,
      column: :access_grant_id,
      on_delete: :cascade
    )
  end
end

When running migration I have the following error :

== 20191104103725 CreateDoorkeeperOpenidConnectTables: migrating ==============
      01 -- create_table(:oauth_openid_requests)
      01    -> 0.0031s
      01 -- add_foreign_key(:oauth_openid_requests, :oauth_access_grants, {:column=>:access_grant_id})
      01 rake aborted!
      01 StandardError: An error has occurred, all later migrations canceled:
      01
      01 Column `access_grant_id` on table `oauth_openid_requests` does not match column `id` on `oauth_access_grants`, which has type `bigint(20)`. To resolve this issue, change the type of the `access_grant_id` column…

      01 Original message: Mysql2::Error: Can't create table `OIDC_welcom_provider_production`.`oauth_openid_requests` (errno: 150 "Foreign key constraint is incorrectly formed")

It appears the default type for id on other tables is bigint, thus the foreign key must match the same type
Rails indeed started using bigint as default a while ago : PR rails/rails#26266

I successfully fixed it locally by editing the generated migration to

class CreateDoorkeeperOpenidConnectTables < ActiveRecord::Migration[6.0]
  def change
    create_table :oauth_openid_requests do |t|
      t.bigint :access_grant_id, null: false
      t.string :nonce, null: false
    end

    add_foreign_key(
      :oauth_openid_requests,
      :oauth_access_grants,
      column: :access_grant_id
    )
  end
end

Anyone ever had the same problem ?

I'm happy to try and contribute the code if there is any guidance on how best to extend this extension to support the implicit grant type?

Hi all,

sorry I am new to this project and topic. I set up doorkeeper and dk-openidconnect.
When trying to authorize I run in to an error in the initialize method at

module PreAuthorization
        attr_reader :nonce

        def initialize(server, client, attrs = {})
          super
          @nonce = attrs[:nonce]
        end
      end

The attrs property is nil if I use the doorkeeper config as recommended:

resource_owner_authenticator do
    if current_user
      current_user
    else
      redirect_to(new_user_session_url)
      nil
    end
  end

The documentation says the resource_owner_authenticator should return something "falsy" if nor user logged in, but I only get this to work when returning an empty hash instead of nil (or false).

Is returning an empty hash ok or am I breaking things helping me this way?

Regards
Andreas

Rails API base controller does not include the "verify_authenticity_token" method, which means the skip check in the userinfo controller raises an exception

Is this as easy as moving the private keys to an environment variable with lines delimited by \n? If so, I can attack. Otherwise if you'd like to point me in the direction regarding how you'd accomplish via a lambda, I'd also be happy to investigate.

Hiya! I was going to fork and put up a pull request, but I figured instead I'd make an issue and get feedback on the approach I was planning.

In a nutshell, it would be nice to support algorithms other than the stock RS256. In particular, I would like to support signing with the algorithms that the omniauth-openid-connect gem supports, outlined on these lines.

Personally, I have a vested interest in supporting the MAC-based algorithms, but naturally we'd like to get to a point where all of the JWA spec is supported. Anyway, my plan was this:

• Add a new configuration option—signing_algorithm—to Doorkeeper::OpenidConnect::Config.
• Add validation to ensure that only the appropriate options are supported.
• Update DiscoveryController to support the different types of algorithms
• Ensure Doorkeeper::OpenidConnect::IdToken supports the different algorithms.

I'm sure I've missed some things, but would a change like this be welcome?

I would like to provide an all_data scope that acts as a summary of more focused scopes (eg profile and email), like so:

  claims do
    # Profile scope
    claim :given_name, scope: :profile do |user, scopes, access_token|
      user.first_name
    end

    # Email scope
    claim :email, scope: :email do |user, scopes, access_token|
     user.email
    end
  
    # All data scope
    claim :given_name, scope: :all_data do |user, scopes, access_token|
      user.first_name
    end
    claim :email, scope: :all_data do |user, scopes, access_token|
     user.email
    end
  end

From my testing, this currently breaks scope requests for just profile or email, because the claims OpenStruct (from ClaimsBuilder) uses the claim symbols as keys, thereby overwriting duplicate claim definitions and only storing the claims under the all_data scope.

I also can't find in the OIDC spec whether it should be possible to have claims assigned to multiple scopes - does anyone know?

Here is the response from POST /oauth/token and there is no id_token return.

{
    "access_token": "9ca3ef6856061bf122e74c25d420430b348b279acd302c1b60f92ae498a92d08",
    "token_type": "bearer",
    "expires_in": 7200,
    "scope": "profile id_token email",
    "created_at": 1499966549
}

BTW I can not get /oauth/userinfo with HEADER Authoraztion: Bearer MY_ACCESS_TOKEN why is that?

My repo is https://github.com/aisensiy/uaa.

For my OP (OpenID Provider) Rails application, I generated just one key-pair with the following commands:

openssl ecparam -genkey -name prime256v1 -noout -out priv-key.pem
openssl ec -in priv-key.pem -pubout -out pub-key.pem

Then I added the Doorkeeper-OpenID-connect routes (use_doorkeeper_openid_connect), which of course includes the OpenID Connect Discovery paths.

Then, after setting everything up properly in order to use the key-pair above, I perform a GET request to the correct Discovery jwks_uri (e.g. https://example.com/oauth/discovery/keys) to get the signing key(s) that an RP (Relying Party) should use to validate the signatures.

Expected response

The output of my request to the jwks_uri should be a JSON-serialized response, structured as a valid JSON Web Key (JWK → RFC-7517) Set containing a single key, whose cryptographic algorithm's properties should be structured according to the JSON Web Algorithms (JWA → RFC-7518) specification. Therefore, it should look more or less like this:

{
  "keys": [ 
    {
      "kty": "EC",
      "kid": "XsXAbPnb1Z25OCWBdrW8112nIuTDfQ8sITTCqELEtbo",
      "x": "7pp2uTZUXR1Vq1EYBPqvpHSt7_TqtBZPVl8nrpLAOpc",
      "y": "IMKuZb2fr7BqnKaHDVIELZJV8RtX1JtN77ZD3fSiO5g",
      "use": "sig",
      "alg": "ES256",
      "crv": "P-256"
    }
  ]
}

Actual response

This is the actual response:

{
  "keys": [ 
    {
      "kty": "EC",
      "kid": "XsXAbPnb1Z25OCWBdrW8112nIuTDfQ8sITTCqELEtbo",
      "x": "7pp2uTZUXR1Vq1EYBPqvpHSt7_TqtBZPVl8nrpLAOpc",
      "y": "IMKuZb2fr7BqnKaHDVIELZJV8RtX1JtN77ZD3fSiO5g",
      "use": "sig",
      "alg": "ES256"
    }
  ]
}

As you can see, it is not that different from what I expected, with the important exception that the crv property is missing.

According to the JWA specs, section 5.2.1, crv is a member that "MUST be present for all Elliptic Curve public keys".

Going further, a short example can be made to highlight the possible bad consequences. Let's suppose to write an RP app which first of all acquires the JWK-Set from the Discovery service of the OP. Then, after a certain event (whose details are irrelevant for this example), the OP sends to the RP a JSON Web Token (JWT) message, signed according to JSON Web Signature (JWS). The RP app starts decoding and validating the JWS string, for example using the json-jwt Ruby Gem, thus invoking the method JSON::JWT.decode, passing to it the raw JWT/JWS string and the JWK-Set data acquired earlier. As a result, the process of decoding and validation fails due to the missing EC Curve (crv) information. In the case of json-jwt Gem, you would get an UnknownAlgorithm error, with message Unknown EC Curve.

Note: I consider the json-jwt Gem being a good example, since it's used in turn by this very Gem.

If you believe this is an actual bug - I mean, a missed specification compliance - I should be able to submit soon a possible fix (unless somebody precedes me, or discards the issue).

Hi, thanks for the great work on this gem. I'm trying to gauge how compatible a recent version of this gem might be with Doorkeeper 5.0.0rc1. I know there's probably not good support for it since it's an RC, but I wanted to ask what options I might have. I'm pinned to rc1 because I need PKCE for my project.

Thanks!

The prompt=login etc is a nice feature to have even for non OIDC requests. Is there a reason why you restrict it to OIDC requests only?

Rails 6 compatibility requires some small changes, mostly in our testing setup and the dummy Rails app in spec/dummy.

Depends on #85

First of all thank you 😃 for all the work that has been put into this project.
It helped me a lot to go get my app running without me needing to understand the specs in detail. 👍 🙏

Background

In the process of switching the access token to a JWT token, I used the doorkeeper-jwt gem as described in the doorkeeper guide and followed their instructions

I generated a new keypair and passed the information onto the secret_key method of doorkeeper-jwt.

Problem

I expected that the new keypair information to be displayed in the jwks_uri from the .well-known/openid-configuration

I discovered that only the one key defined in the doorkeeper-openid_connect configuration will be displayed in the jwks_uri URL

Question

1. Would it be possible to have a configuration where multiple keys are support?
   Multiple OAuth providers (AWS Cognito or 0Auth) use this principle.
   As this allows for a lot of flexibility in for example deprecating keypairs slowly

2. Additionally building on top of the assumption to have multiple key support. How could you get access to the keypair defined in the doorkeeper-jwt configuration? (Maybe this should be placed as a separate issue and maybe here is also not the right place but either the doorkeeper-jwt or doorkeeper if that is the case please let me in the comments)

ps. I hope this issue is as expect other also let me know and I'll adjust it accordantly

Doorkeeper 5.2 introduced some breaking changes, see #83

This is now being worked on in #85

Hello @toupeira, great work getting this gem cleaned up after the change in ownership. I was wondering what issues are in the way of releasing version 1.0.3? I've integrated it locally, and it seems to work as expected, but don't think I wanna ship it with a github link in the gem file :)

Sorry if this is a weird place for this question, I'm not sure how else to ask this.

I use doorkeeper config:

# config/initializers/doorkeeper.rb
...
access_token_class 'Oauth::AccessToken'
access_grant_class 'Oauth::AccessGrant'
application_class 'Oauth::Application'

Call POST "/oauth/token" I get:

NoMethodError (undefined method `openid_request' for #<Oauth::AccessGrant:0x00005593c7743f28>):

activemodel (6.0.3.2) lib/active_model/attribute_methods.rb:432:in `method_missing'
doorkeeper-openid_connect (325068fd2f38) lib/doorkeeper/openid_connect/oauth/authorization_code_request.rb:13:in `after_successful_response'
doorkeeper (5.4.0) lib/doorkeeper/oauth/base_request.rb:16:in `authorize'

If I remove access_grant_class 'Oauth::AccessGrant' config. All works fine.

Here my Oauth::AccessGrant class:

module Oauth
  class AccessGrant < ApplicationRecord
    include ::Doorkeeper::Orm::ActiveRecord::Mixins::AccessGrant
  end
end

Maybe in this line:

the access_grant_class config must be used if set in config.

Workaround

module Oauth
  class AccessGrant < ApplicationRecord
    include ::Doorkeeper::Orm::ActiveRecord::Mixins::AccessGrant

    # Bugfix: see https://github.com/doorkeeper-gem/doorkeeper-openid_connect/issues/127
    has_one :openid_request,
            class_name: 'Doorkeeper::OpenidConnect::Request',
            inverse_of: :access_grant,
            dependent:  :delete
  end
end

doorkeeper has some deprecation warnings when running it with ruby 2.7 and they are fixed on Doorkeeper 5.5.0 but the gemspec of doorkeeper-openid_connect is not allowing doorkeeper 5.5.0:

Do you know if there is any change in doorkeeper 5.5.0 that breaks doorkeeper-openid_connect? if not, could we support doorkeeper 5.5.0?

Thanks