Problem/Motivation

client_secret is hardcoded to certain length: 1024 and prohibits longer keys such as JWT private keys.

Proposed resolution

  • Extent field to 5096
  • Refactor retrieveTokens for authentication token to be easily overridable
CommentFileSizeAuthor
#5 openid_connect-maxlength-3188143-4.patch574 bytesvladimiraus
#3 openid_connect-maxlength-3188143-2.patch2.34 KBvladimiraus

Issue fork openid_connect-3188143

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

VladimirAus created an issue. See original summary.

VladimirAus opened merge request !4

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Active » Needs review
StatusFileSize
new openid_connect-maxlength-3188143-2.patch2.34 KB

Patch added.

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Needs review » Needs work

A lot of this patch is a duplicate of #3187322: In retrieveTokens, obtain request_options from a protected function. Can you please comment and review on that section of the patch in that issue, please?

Please create a new patch just for the new client_secret length.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Needs work » Needs review
StatusFileSize
new openid_connect-maxlength-3188143-4.patch574 bytes

Thanks for the review @jcnventura. Reverted back both in PR and with patch.

jcnventura’s picture

jcnventura
Primary language English
commented

Thanks for this.. Where does the 5096 number come from? It seems to be 4K + 1000, and I don't understand why.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented

Team reported it was enough to store private key.
I would assume it was 4K + extra comments which private key usually comes with.

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Needs review » Postponed (maintainer needs more info)

I'd assume that a client secret is converted using a process like base64 which converts 3 bytes of data into 4 characters (=bytes).

So, a 1024 character field (i.e. 8192 bits) can hold a 6144-bit key. A 5096 character field can hold a 30576-bit key...

I concede that 1024 is somewhat small for the case of a 8192 or even a crazy 16384-bit secret.. But even the crazy 16384-bit secret would only need 2731 characters.

This to say that without a realistic reason to change the value, I'll keep it as is for the time being.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Postponed (maintainer needs more info) » Needs review

In my situation I need to cater for JSON Web Token (JWT) length of 4096 + comments.

There is no maximum length defined in the RFC7519 (https://tools.ietf.org/html/rfc7519) or other RFCs related to JWS or JWE. If you use the JSON Serialized format or JSON Flattened Serialized format, there is no limitation and there is no reason to define a limitation.

So, do you want to convert it to text area?

  • jcnventura authored e4f586c on 2.x 
    Issue #3188143 by VladimirAus, jcnventura: client_secret is hardcoded to...

  • jcnventura authored e78902d on 8.x-1.x 
    Issue #3188143 by VladimirAus, jcnventura: client_secret is hardcoded to...
jcnventura’s picture

jcnventura
Primary language English
commented
Status: Needs review » Fixed

Yes, a textarea makes a lot more sense.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented

Thanks @jcnventura

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.