-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
1.0.2
-
Minor
Problem
When a remote application tries to obtain an access token using PKCE workflow Jira blocks the request expecting a client secret. While the whole purpose of "Proof Key for Code Exchange" is to not use stored secrets.
Environment
- Jira 9.15.2
Steps to Reproduce
- Create an incoming application link on Jira
- Generate a code verifier and a code challenge for the remote application
- Consent on the link , GET https://JIRA-HOST/jira/plugins/servlet/oauth2/consent?client_id=V1&redirect_uri=V2&response_type=code&scope=V3&code_challenge_method=S256&code_challenge=V4
- Copy the code from the redirection URL from the previous step , copy the code verifier from the second step
- Send a POST request to : https://JIRA-HOST/jira/rest/oauth2/latest/token?client_id=V1&code=V2&grant_type=authorization_code&redirect_uri=V3&code_verifier=V4
Expected Results
Jira will return an access token to be used by the remote application with response code 200
{
"scope": "SYSTEM_ADMIN",
"access_token": "eyJhbGciOiJIUzI1NiJ9.eyJpZCI6ImY2MTViMTdiNDVjMzMxMDU2MTBmMmMwZjQ0N2MwM2E5In0.geCLYxFBbJOOuQa1Z3wpLWl4w-M49l6b76aAKm_6Kzg",
"token_type": "bearer",
"expires_in": 3600,
"refresh_token": "eyJhbGciOiJIUzI1NiJ9.eyJpZCI6ImIzYjlmODg0N2M2ODdhYjcwMzRkZmUzYWYxODUzZWI1In0.mFoOTFD1OIhFt7u9i5Ge2AP9fG_8DmGmuyleGkftUrQ"
}
Actual Results
Jira returns 401 asking for client_secret
Workaround
Following Setting properties and options on startup add the value
-Datlassian.oauth2.provider.validate.client.secret=false
Notes
- Using the mentioned workarround will stop Jira from verifying all the stored client_secrets , this might have a global security impact so be sure to use the workarround only if all remote apps should work only with the less secure PKCE method
- causes
-
ECOHELP-39584 Failed to load
- is cloned by
-
KRAK-6134 You do not have permission to view this issue
[OAUTH20-2491] Jira oauth-2 implementation doesn't respect PKCE standard
Section 4.1.3 says:
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
It doesn't say that is HAS to be a confidential client. The REST API documentation says that public clients are allowed, but its impossible to create an Application Link that is not a confidential client.
I agree, I don't think this is an issue.
Here is some more info on MS's official docs linking back to the same RFC Jon has linked above:
[Microsoft identity platform and OAuth 2.0 authorization code flow - Microsoft identity platform | Microsoft Learn|https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow]
Just looking through all the work you guys are doing, thank you so much.
I ended up here because I came to log this ticket initially:
OAUTH20-2493 Specify Allow/Block Lists for OAuth 2.0 (3LO) Apps - Create and track feature requests for Atlassian products.
I would really appreciate any initial response/plans you may have concerning this.
Just a point of clarification, this prevents the use of a "public client" from using Application Links for the REST API, which specifically states:
This flow lets you securely perform the OAuth exchange of client credentials for access tokens on public clients.
Source: https://developer.atlassian.com/server/confluence/confluence-oauth2-provider-api/
Can we please fix this for ALL Atlassian products? This makes it so difficult trying to integrate any non-Atlassian application with Atlassian tools.
The purpose of PKCE is not to avoid storing secrets. It is to mitigate authorization code interception attacks (as detailed in RFC7636). Authentication must still happen.
Per section 4.5 of the PKCE specification an "Access Token Request" is sent to the token endpoint with the code_verifier as an additional parameter. The base request is the "Access Token Request" as described in section 4.1.3 of the OAuth 2.0 specification. Per section 3.2.1 confidential clients must authenticate. In the case of Jira this is done via a client password as described in section 2.3.1.
This is true for confidential clients, but not public clients. Public clients, like an SPA that cannot securely store secrets, must use the Authorization code flow with PKCE to overcome this.
We've just recently upgraded to Confluence 9.2.1, and the Authentication flow with PKCE is working as expected. We do not have to supply a client secret to access the REST API endpoint.