Path parameters of App Store Connect API

Hey @taktem,

Thanks so much for posting on the Apple Developer Forums!

I had never worked on this before now so I was tinkering around and I think I found what could be holding you up (or at least what held me up).

The first issue that I ran into when trying to figure this out was that the App Store Connect API documentation appears to need some updating. I have filed a feedback for this (FB10036380). You will need to update your "scope" to the below code example.

“scope”: [
        “GET /builds/{id}/app”
    ]

Currently, including the /v1 as a part of the scope path will return an error from the App Store Connect API which does not match their documentation. By removing the /v1 things started to work for me.

There are many ways to accomplish what to put in the scope path, and I have not fully tested if the API accepts wildcards, but in this specific example, you would need to have some information beforehand or you would need to dynamically generate tokens on the fly and return them to the system wanting to make a request. A bit past the scope (no pun intended) of this response but I will give you one example.

In order to limit the scope of the Read the App Information of a Build API, you would first need to know all of the Build IDs and include those in the array of the scope permissions. To do this, you would need a JWT without a scope limitation to hit the List Builds API and then find the IDs from the response and generate a new JWT to be exchanged for a token.

Below is an example of what this would end up looking like (IDs are fake and generated by uuidgen).

“scope”: [
        “GET /builds/4E01297D-1D43-4020-B21C-9DC94A40579B/app”,
        “GET /builds/A72021D3-8712-445D-9585-B847BBCCA362/app”,
        “GET /builds/65E73521-ED9A-4F06-9C5D-44B54BB34ED6/app”,
        “GET /builds/1FAC0D8D-4FD5-4ECD-9B84-D1422ADE3003/app”
    ]

There are many ways to go about achieving what you are looking to do so I would explore how to implement this logic upstream as a part of an initial request, but that is just how I like to build things.

Hopefully this helps and happy coding!

Dear @ChuckMN,

Thanks for your reply.

It is worked if not contain the path parameter in my environment.

For example, this is worked.

"scope": [
    "GET /v1/apps",
]

But this is not work.

"scope": [
    "GET /v1/builds/{id}/app"
]

I've tried some patterns, but it’s not work at all.

I have not fully tested if the API accepts wildcards

I was able to allow it by getting specific IDs and making them explicit for each scope, as you recomend.
However, I would like to allow paths that include a path parameter, e.g., using wildcards.

I haven't found a solution yet.
If you know how to use wildcards that would be great!

Hey @taktem,

No problem at all! We are all here to learn!

So I tried to validate what you have posted above using all of the documented implementation information that Apple provides, and I am not able to replicate your findings. Specifically, if I include /v1/apps as the scope of my JWT, I am not able to successfully interact with the API. However, when I remove the '/v1' portion from the request, I am capable of hitting the API successfully.

When trying to replicate your environment, would it be possible for you to share your full JWT composure code so that we can see what it looks like? Would be interesting to see if you are seeing something that Apple is not expecting so that the paths do not align.

One other thing that might be of interest that I could help validate is the different API Key permissions. What API Key type are you using?

Specifically for wildcards, I would strongly recommend opening up a Feedback with Apple for this so that they can evaluate it and determine whether or not this fits within their current authentication model. I know that they are moving away from wildcards in many other places within the Apple ecosystem so it would be great to file a Feedback and get information from Apple directly on the direction they are going since wildcards can act as a very broad attack vector if the token were to fall into the wrong hands.

Hopefully this helps some and happy coding!

Dear @ChuckMN,

Thank you for your reply.

Certainly there are concerns about flexible scopes.
I am convinced by what you said.
I was hoping to avoid having to spend time generating Tokens each time, but perhaps that is something we should accept.

would it be possible for you to share your full JWT composure code so that we can see what it looks like?

I was able to generate Token with this code

func generateAppStoreConnectToken(scopes []string) string {
	p8bytes, _ := os.ReadFile(os.Getenv("API_KEY_FILE_PATH"))
	decoded, _ := pem.Decode(p8bytes)
	parsedKey, _ := x509.ParsePKCS8PrivateKey(decoded.Bytes)
	ecdsaPrivateKey, _ := parsedKey.(*ecdsa.PrivateKey)
	claims := jwt.MapClaims{
		"iss":   os.Getenv("API_KEY_ISSUER_ID"),
		"iat":   time.Now().Unix(),
		"exp":   time.Now().Add(20 * time.Minute).Unix(),
		"aud":   "appstoreconnect-v1",
		"scope": scopes,
	}
	token := jwt.NewWithClaims(jwt.SigningMethodES256, claims)
	token.Header["kid"] = os.Getenv("API_KEY_KEY_ID")
	tokenString, _ := token.SignedString(ecdsaPrivateKey)
	return tokenString
}

token := generateAppStoreConnectToken(
    []string{
        "GET /v1/apps",
    },
)

Since this is an experimental code, error handling is omitted.

As a test, I excluded /v1 from the request Scope and the API call failed.

The error message is as follows
"The request RequestData(method=GET, path=/v1/apps, query=null) does not match any authorized scope: [RequestData(method=GET, path=/apps, query=null)]"

Wildcards continued to be unavailable, but your advice helpful for me.
I will be aware of the safe Token scope.
Thank you!