• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      User Problem

      I’m developing a desktop application (in C# / .NET) that needs to use the Jira Cloud REST API on a user's behalf.

      I was reading this article about OAuth 2.0 (3LO) which explains how to use Authorization Code grant flow. However, in this article, we're using a Client Secret to exchange the authorization code for an access token.

      Since my application is a desktop application, it should be considered as a public (non-confidential) client. All application's binaries and files are copied into local file system. Since they can be easily decompiled and inspected by anyone having an access to file system, desktop applications should not contain any secrets.

      Suggestion Solution

      Desktop applications should use Authorization Code grant flow with PKCE extension to authorize user and to avoid storing any secrets on user's device.

      This request is to ask for the PKCE extension to be added to the Authorization Code grant flow for the Jira Cloud Rest API.

      Current Workaround

      A possible work-around (less than ideal user experience), is that each of user generates their own client id & secret, stores it in their local environment, and then your app can mediate the authorization code flow using those unique credentials.

      Additional Note

      Please note that the public suggestion OAUTH20-2491 logged for PKCE explicitly mentions an on-prem Jira version. Atlassian treats bugs separately for Cloud vs Server/DC. As such, I'm logging this new feature request specifically for Cloud.

      Also, this request doesn't concern Forge and Connect apps. However, there is no suitable component available. I was forced to select a Forge and Connect component.

            [ECO-283] OAuth 2.0 with Proof Key for Code Exchange (PKCE)

            This is also hindering me from developing a CLI tool.

            Joseph Cordasco added a comment - This is also hindering me from developing a CLI tool.

            Eliott added a comment -

            Same needs here, for a Single Page App

            Eliott added a comment - Same needs here, for a Single Page App

            JD added a comment -

            I think this should be treated as a VULN.

            Also, it's already possible to use PKCE with Jira Cloud OAuth Consumers, but it relies on someone internally at Atlassian (specifically on the id team I believe) to flip a flag on the consumer to enable PKCE.

            see: https://bitbucket.org/atlassianlabs/atlascode/src/b10421441de5e51ffbba0e91a09ce98ba32c29f2/src/atlclients/strategy.ts#lines-6

            This should just be an option in the dev console when setting up a new consumer.

             

            JD added a comment - I think this should be treated as a VULN. Also, it's already possible to use PKCE with Jira Cloud OAuth Consumers, but it relies on someone internally at Atlassian (specifically on the id team I believe) to flip a flag on the consumer to enable PKCE. see: https://bitbucket.org/atlassianlabs/atlascode/src/b10421441de5e51ffbba0e91a09ce98ba32c29f2/src/atlclients/strategy.ts#lines-6 This should just be an option in the dev console when setting up a new consumer.  

            I am also building a public client and need PKCE.

            Martin Jaskulla added a comment - I am also building a public client and need PKCE.

            This suggestion was created following a discussion on the Atlassian developer community:

            https://community.developer.atlassian.com/t/oauth-2-0-with-proof-key-for-code-exchange-pkce/80173

            François Chartrand added a comment - This suggestion was created following a discussion on the Atlassian developer community: https://community.developer.atlassian.com/t/oauth-2-0-with-proof-key-for-code-exchange-pkce/80173

            François Chartrand added a comment - - edited

            Refer to RFC-7636 for the full standard documentation.

            François Chartrand added a comment - - edited Refer to RFC-7636 for the full standard documentation.

              Unassigned Unassigned
              ebb98b719f06 François Chartrand
              Votes:
              24 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated: