Hi - I am an Atlassian engineer who works on Bitbucket Cloud's OAuth infrastructure.
An impending OAuth2 change in Bitbucket Cloud will cause the OAuth2 access tokens (and refresh tokens) generated by the client used by the GCM to regularly exceed the limits of the default credentialStore implementation on windows wincredman. This causes a complete failure during the refresh_token flow and initial authorization_code grant flows.
The error is as follows:
fatal: Failed to write item to store. [0x6f7]
fatal: The stub received bad data
The reason for the increase of token size is a change in our backend OAuth implementation. This change brings in rotating refresh tokens, and a swathe of other security uplifts. The downside is the tokens are slightly over the character limits imposed by the wincredman which is 2,560 bytes.
This can be remedied by swapping to use the dpapi credentialStore which doesn't have such trivial limits on credential limits. This obviously requires a command line option to be run to swap, but is a pretty minimal change to keep OAuth working. I am not sure if swapping the credentialStore would copy across the refresh_token though, but I would hope there would be some chain of commands that will enable users to keep their authorizations.
An alternative could be splitting and storing the refresh / access tokens in smaller parts, stitching them back together. However this seems undesirable as it would require a version upgrade to continue using the GCM to auth.
Just wondering if any of the other OAuth providers have run into this - or if you have any other thoughts / remedies. We're currently exempting the OAuth client from the rollout. Another thing I found in my travels is that the GCM is re-using the Source Tree app OAuth client.
I'd love to change this over to use a unique OAuth client for GCM - but that's probably a problem for another day - and would require users to go through a full 3LO authorization flow.
Best regards,
Daniel Fraser
More details about the OAuth changes here: See: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052)
Hi - I am an Atlassian engineer who works on Bitbucket Cloud's OAuth infrastructure.
An impending OAuth2 change in Bitbucket Cloud will cause the OAuth2 access tokens (and refresh tokens) generated by the client used by the GCM to regularly exceed the limits of the default credentialStore implementation on windows
wincredman. This causes a complete failure during therefresh_tokenflow and initialauthorization_codegrant flows.The error is as follows:
The reason for the increase of token size is a change in our backend OAuth implementation. This change brings in rotating refresh tokens, and a swathe of other security uplifts. The downside is the tokens are slightly over the character limits imposed by the
wincredmanwhich is 2,560 bytes.This can be remedied by swapping to use the
dpapicredentialStore which doesn't have such trivial limits on credential limits. This obviously requires a command line option to be run to swap, but is a pretty minimal change to keep OAuth working. I am not sure if swapping thecredentialStorewould copy across therefresh_tokenthough, but I would hope there would be some chain of commands that will enable users to keep their authorizations.An alternative could be splitting and storing the refresh / access tokens in smaller parts, stitching them back together. However this seems undesirable as it would require a version upgrade to continue using the GCM to auth.
Just wondering if any of the other OAuth providers have run into this - or if you have any other thoughts / remedies. We're currently exempting the OAuth client from the rollout. Another thing I found in my travels is that the GCM is re-using the Source Tree app OAuth client.
I'd love to change this over to use a unique OAuth client for GCM - but that's probably a problem for another day - and would require users to go through a full 3LO authorization flow.
Best regards,
Daniel Fraser
More details about the OAuth changes here: See: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052)