Allow the use of unhashed secrets #1311
Conversation
|
Please request a review when you are ready.... |
Codecov Report
@@ Coverage Diff @@
## master #1311 +/- ##
==========================================
+ Coverage 97.37% 97.39% +0.01%
==========================================
Files 32 32
Lines 2022 2035 +13
==========================================
+ Hits 1969 1982 +13
Misses 53 53
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
@n2ygk it seems I am unable to request a review through the UI, but feel free to review the PR |
Looks like you added them (or someone did) |
|
I am not sure what you are talking about :( The reviewers section is empty. |
Haha I was looking at my suggestions:
|
There was a problem hiding this comment.
This looks great but please do the following additional:
- add the option to the HTML template for application registration
- Add option to
createapplicationmanagement command - document that new
hash_client_secretoption more thoroughly. See, for example references to hashing in getting_started and tutorial_01 (including screen shots).
|
@Andrew-Chen-Wang I've added you as a reviewer mostly as an FYI. |
|
@n2ygk I have updated your points, thanks for the feedback |
|
Looks like pytest broke probably due to some version issue. Will look at it tomorrow or Thursday |
|
Hmm a migrations conflict: |
Co-authored-by: Alan Crosswell <[email protected]>
|
My fault. I merged #1312 which created the migration conflict. Fixing it now. |
|
I know I can install this from git but I think this fix is important enought to create a new release on PyPI. Thank you for your work :) |
jazzband/django-oauth-toolkit#1311 was merged, but still not released. We would like to use it, so...
|
@n2ygk (from one ham radio op to another 🥲) any chance of a release with this fix in the near-ish future? |
In newer DOT than what AWX uses, Application.client_secret is hashed automatically with no way to disable that functionality. There's a PR that allows for disabling that functionality ([0]), but that hasn't made it into a release. The DOT hashing is incompatible with our standard encryption - when DOT gets the value it ends up getting our encrypted string and trying to act on that. Ideally we'd like to disable their hashing entirely and use our standard encryption tooling. AWX avoids this problem by pinning to an older DOT. For now in DAB we'll just use the upstream hashing, and not treat the field as an encrypted_fields field to avoid the "double encryption" issue. [0]: jazzband/django-oauth-toolkit#1311 Signed-off-by: Rick Elrod <[email protected]>
In newer DOT than what AWX uses, Application.client_secret is hashed automatically with no way to disable that functionality. There's a PR that allows for disabling that functionality ([0]), but that hasn't made it into a release. The DOT hashing is incompatible with our standard encryption - when DOT gets the value it ends up getting our encrypted string and trying to act on that. Ideally we'd like to disable their hashing entirely and use our standard encryption tooling. AWX avoids this problem by pinning to an older DOT. For now in DAB we'll just use the upstream hashing, and not treat the field as an encrypted_fields field to avoid the "double encryption" issue. [0]: jazzband/django-oauth-toolkit#1311 Signed-off-by: Rick Elrod <[email protected]>
In newer DOT than what AWX uses, Application.client_secret is hashed automatically with no way to disable that functionality. There's a PR that allows for disabling that functionality ([0]), but that hasn't made it into a release. The DOT hashing is incompatible with our standard encryption - when DOT gets the value it ends up getting our encrypted string and trying to act on that. Ideally we'd like to disable their hashing entirely and use our standard encryption tooling. AWX avoids this problem by pinning to an older DOT. For now in DAB we'll just use the upstream hashing, and not treat the field as an encrypted_fields field to avoid the "double encryption" issue. [0]: jazzband/django-oauth-toolkit#1311 Signed-off-by: Rick Elrod <[email protected]>
In newer DOT than what AWX uses, Application.client_secret is hashed automatically with no way to disable that functionality. There's a PR that allows for disabling that functionality ([0]), but that hasn't made it into a release. The DOT hashing is incompatible with our standard encryption - when DOT gets the value it ends up getting our encrypted string and trying to act on that. Ideally we'd like to disable their hashing entirely and use our standard encryption tooling. AWX avoids this problem by pinning to an older DOT. For now in DAB we'll just use the upstream hashing, and not treat the field as an encrypted_fields field to avoid the "double encryption" issue. [0]: jazzband/django-oauth-toolkit#1311 Signed-off-by: Rick Elrod <[email protected]>
In newer DOT than what AWX uses, Application.client_secret is hashed automatically with no way to disable that functionality. There's a PR that allows for disabling that functionality ([0]), but that hasn't made it into a release. The DOT hashing is incompatible with our standard encryption - when DOT gets the value it ends up getting our encrypted string and trying to act on that. Ideally we'd like to disable their hashing entirely and use our standard encryption tooling. AWX avoids this problem by pinning to an older DOT. For now in DAB we'll just use the upstream hashing, and not treat the field as an encrypted_fields field to avoid the "double encryption" issue. [0]: jazzband/django-oauth-toolkit#1311 Signed-off-by: Rick Elrod <[email protected]>
|
FYI - as part of the release, I'm strengthening the language to recommend using RS256 keys which is a more secure approach than HS256 and does not require retaining the |
* in-process release 2.4.0 pending some late PR merges. * Update #1311 documentation to recommend using RS256 rather than HS256. * editorial changes to CHANGELOG * fix line too long
Although I think I know the answer, I have a clarification question. Does the "This" in this sentence mean that:
? Because it isn't 100% perfectly clear here to me, and I'm not an expert on OIDC. Once I get an answer I'll provide a PR to tweak/fix the language. |
|
When the box is checked and HS256 is used with OIDC. HS256 requires that the token is signed by a symmetric key that is shared between the Relying Party and the Authorization Server. The application's secret is used for this signature. When you leave "hash secret" checked, the Authorization Server will lose the original secret value and will use the hashed secret when signing the token. But this breaks the OIDC's contract as the Relying Party is no longer able to verify the token's signature. The token is completely valid from the OAuth Toolkit's viewpoint - you can use it to authenticate against Django views, etc. You can leave "hash secret" checked without any problems if you:
|
|
@gardenerik Thanks for the explanation, that's what I thought. I'll whip up a PR to tweak the help text to be a tiny bit more clear about what state it's referring to. As a slightly separate issue: when a user unchecks the box and uses HS256 with OIDC, does it make sense to leave the (unhashed) symmetric key visible to the user on future page loads? It seems to me that a lot of secret values are only shown once to the user (this is exactly how GitHub works with developer keys), and I assume that this is done to make it more difficult for an attacker to steal or the secret from the OIDC provider and/or spoof the provider entirely (with the correct shared secret). When a user chooses to leave the "hash secret" option checked when registering an application with django-oauth-toolkit, it looks a bit unpolished to me to display the hashed value in the form again on subsequent page loads, so I'm considering a second PR to only show the secret value once, when it is generated. But I want to make sure I support the HS256+OIDC flow as well in that PR. Thanks! |
Fixes #1239
Description of the Change
Adds an option to disable client secrets hashing on save. Also allows the use of applications with unhashed secrets in the HTTP API. This makes it possible to verify OIDC JWTs with HS256.
Checklist
CHANGELOG.mdupdated (only for user relevant changes)AUTHORS