Couple of 3LO questions

I’m looking at building a new 3LO app but am pretty to new to all this TBH. I’ve built a small test app following What I can’t seem to find though is information on how long the authorization code is valid for? I can find the lifetime of the access code and refresh codes etc but not this initial step.

The reason I ask is that as I was just messing about I didn’t code my call to get an access token immediately off the back of getting an authorization code and I noticed that it all seemed to work fine if I applied for the access token pretty quickly after getting the auth code but if I left it more than a few minutes I’d get:
400 Bad Request: “{“error”:“invalid_request”,“error_description”:“authorization_code is invalid”}”

Also can someone confirm whether the V2 confluence REST API can be used with oauth 3LO apps? The app setup only seems to allow classic/granular scopes from the V1 set…




Our docs have a tendency to assume general knowledge of OAuth 2.0 spec, which can certainly be confusing if this is your first time working with OAuth. The short answer is the authorization will expire after 10 mins (and maybe less), per RFC 6749 section 4.1.2:

REQUIRED. The authorization code generated by the
authorization server. The authorization code MUST expire
shortly after it is issued to mitigate the risk of leaks. A
maximum authorization code lifetime of 10 minutes is
RECOMMENDED. The client MUST NOT use the authorization code
more than once. If an authorization code is used more than
once, the authorization server MUST deny the request and SHOULD
revoke (when possible) all tokens previously issued based on
that authorization code. The authorization code is bound to
the client identifier and redirection URI.

The scopes are not specific to a version of the API. I didn’t see any indication in the dev console that they might be. Is there somewhere else that gave you the impression that scopes were version-specific?

Hi ibuchanan,

Thanks for your response! On reflection, I assumed something like that, thanks - sorry I should have checked for that.

In terms of the scopes, I think I’m just being a muppet - all API V2 scopes are treated as being granular and are present along with V1 non-classic scopes under the granular tab when configuring permissions for the app and it seems you cant mix classic and granular under the same token - think I just missed that and mistook what was going on when confusing some of the scope names.