Allow public clients to authenticate without client_secret #1031

f3ndot · 2018-02-10T21:43:35Z

Summary

This PR aims to solve #999 and comply with Section 8.5 of draft-ietf-oauth-native-apps-12:

   Secrets that are statically included as part of an app distributed to
   multiple users should not be treated as confidential secrets, as one
   user may inspect their copy and learn the shared secret.  For this
   reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT
   RECOMMENDED for authorization servers to require client
   authentication of public native apps clients using a shared secret,
   as this serves little value beyond client identification which is
   already provided by the "client_id" request parameter.

Public vs Private Clients

The original OAuth 2 RFC makes a definition between public & private clients (Section 2.1). To this end, along with modeling industry best practice, Doorkeeper::Application now has a #confidential? attribute. The developer must decide when creating an application, whether it is to be a confidential or non-confidential client.

This allows Doorkeeper to behave differently when receiving an authentication request, depending on the identified client and its confidentiality.

This decision maintains security by forcing the presence of a client_secret when the developer intends their app only to be used in secure environments.

For backwards compatibility, an UPGRADING.md document should be written asking developers to generate a migration that adds the confidential column. To be safe by default, the default value/backfill should be a confidential app.

What's Next

I omitted some important work to keep this PR simple:

There's no tracking in the Doorkeeper::AccessToken for whether or not it was created under authenticated means (confidential app) or just identified (public app). A future PR should do this so it is clear to the developer that that Access Token's application relationship is guaranteed or just claimed.
We don't forbid certain grant types depending on the confidentiality of an app. For example, a public app cannot use Authorization Code (unless PKCE). Research on the RFC specs is required, to determine if/how we may prevent a public client from authenticating using a grant type intended for private apps and vice versa.

houndci-bot · 2018-02-10T21:43:46Z

spec/requests/flows/password_spec.rb

-      token = Doorkeeper::AccessToken.first
+      context "when client_secret absent" do
+        it "should not issue new token" do
+          expect do


Parenthesize the param change { Doorkeeper::AccessToken.count } to make sure that the block will be associated with the change method call.

houndci-bot · 2018-02-10T21:43:46Z

spec/requests/flows/password_spec.rb

+
+        context "when client_secret incorrect" do
+          it "should not issue new token" do
+            expect do


Parenthesize the param change { Doorkeeper::AccessToken.count } to make sure that the block will be associated with the change method call.

houndci-bot · 2018-02-10T21:43:46Z

spec/requests/flows/password_spec.rb

-      expect do
-        post password_token_endpoint_url(client: @client, resource_owner: @resource_owner)
-      end.to change { Doorkeeper::AccessToken.count }.by(1)
+    context "with non-confidential/public client" do


Block has too many lines. [29/25]

houndci-bot · 2018-02-10T21:43:46Z

spec/models/doorkeeper/application_spec.rb

-        app = FactoryBot.create :application
-        authenticated = Application.by_uid_and_secret(app.uid, app.secret)
-        expect(authenticated).to eq(app)
+    describe :by_uid_and_secret do


Block has too many lines. [30/25]

houndci-bot · 2018-02-10T21:43:46Z

spec/dummy/db/migrate/20180210183654_add_confidential_to_application.rb

@@ -0,0 +1,11 @@
+class AddConfidentialToApplication < ActiveRecord::Migration[5.1]
