I followed the steps outlined in https://developer.atlassian.com/cloud/jira/platform/oauth-2-3lo-apps/. Would anyone know what is the length of the authorization code? The returned code in the callback URL is 858 chars long. Is that normal? Refer to the snapshot.
Welcome to the Atlassian developer community @AnthonyGriffiths,
The authorization code is a type of Atlassian security token, we consider to be opaque; hence, clients cannot depend on their size, structure, or format. That said, yes, both the length and encoding (looks like JWT to me) are normal for the current OAuth 2.0 implementation. Was there an implication of this length that concerns you?
Thank you for the reply. No concerns here. Iâm just a newbie tasked to port our API client from JIRA DC to Cloud using token based authentication/authorization instead of the account/password method originally used for the DC. I have no experience on this OAuth stuff.
Below is what I have learnt so far. Any advice is appreciated.
Our API client is written in C# and uses the Atlassian.SDK 13.0 package downloaded from the NuGet repository. Atlassian.SDK package appears to wrap around RESTSHARP which in turn wraps around HTTPCLIENT.
I notice this package offers 2 authentication options.
a. Basic Authorization using Account/password
b. Authentication 1.0 (consumer key/consumer secret/token access/token secret).
According to Atlassian, the Cloud version does not support these above options.
So, this leaves me other 2 options which are supported for the Cloud version. To make this matter worse, the Atlassian.SDK 13.0 package appears not to offer these options.
c. Basic Authorisation using API token created via the account profile. The token is of this format âemailaddress:APITokenâ.
d. Authentication 2.0 ( which requires developer console to create the access token etc).
Atlassian recommends option (c) should be used for simple ad-hoc script or program. It is not as strong as option (d) - Authentication 2.0.
I was able to write a simple C# test program (using httpclient) to access my sandbox Jira successfully using both options (c) and (d). However, I believe the implementation of option (d) will be harder as I will have to use refresh tokens to extend the life of session. Apparently, a token lasts 60 mins.
Once again any advice is appreciated. I admit I still have some learning curve to go.
I wouldnât recommend that package if you were on Server/DC. Itâs unmaintained and the last version it was tested on is now well outside of Atlassianâs support window. I certainly donât recommend it for Cloud where the REST APIs can be quite different on more than just auth.
I havenât programmed in C# for almost a decade, but I have seen a lot of API client styles. I would recommend refit because it helps âbindâ the API client to your own classes. This strikes a good balance because it lets you pick the parts of the API you want to be coupled to (rather than assume the whole API). Meanwhile, the abstraction is so light that you can pick any parts of API and implement them quickly.
Refit doesnât really solve your auth problem, in the sense that you still have to implement some of the Atlassian logic in your client. Basic auth is basic auth regardless of password or API token. The pattern is exactly the same for structuring and encoding those values. Itâs the simplest option.
OAuth is preferred both by us and typically by customer admin & security teams. That said, Atlassianâs implementation is somewhat limited: it only implements the authorization code flow (we refer to it as 3LO), which tends to assume a web client. If you are building a headless integration and just want âsystem to systemâ auth, then our implementation is somewhere between difficult and the wrong OAuth flow.
One of the reasons to choose your auth strategy at the start, rather than go with simple basic auth and change later, is that URL construction is different between the auth methods. For basic with API tokens, itâs just your base URL + a path. For OAuth thereâs a gateway where the base URL is api.atlassian.com + a Jira path with your cloud id + the REST API path. This can make switching from basic to OAuth tricky, if you havenât factored out URL construction from the start.
Hope that helps you make some good technical design decisions.
Thank you for the reply. First of all, I agree with everything you mentioned. Like you, I have not programed in C# for 10 years! :-). I will dump Atlassian.SDK as I felt it is not the worth the bother considering my API Client invokes only 3 JIRA functions.
a) rest/api/2/search
b) rest/api/2/project
c) rest/api/2/issue/{id}
My API Client is simply a report generator extracting data from Jira. It is not a web client. As you mentioned above, implementing the OAuth 2.0 will be tricky at the machine-2-machine level. I will have to make a decision on which basic or Oauth 2.0 should I use.
I have shared 2 sample C# programs for anyone who wants to learn basic auth. Each program use RESTSHARP and HTTPCLIENT separately. The third one is a class (incomplete) used for JSON deserialisation.
The sample C# Oauth 2.0 program will be forthcoming once I figured out how to use the re-fresh token after the token expires. NB: To get the refresh token I appended âoffline_access20%â in the scope parameter.
Cheers, Anthony
1 Like