App Store Connect API 4.5.1 Touches Nothing Your Identity Stack Depends On

I read the 4.5.1 release notes so you don’t have to. There is nothing in them for anyone who runs authentication for a living. No change to Sign in with Apple’s token endpoints, no change to App Attest or DeviceCheck, no new signing-certificate requirement, no notarization shift. If you were paged about this, go back to bed.

That’s the whole verdict. But “nothing happened” is worth exactly two minutes of your time, because the reflex to skim a developer-tooling release and assume it can’t touch identity is how people miss the one release where it does. So here’s the timeline, annotated, including the dated thing that will bite you — which is not in this release, and that’s the point.

October 6, 2026 — 4.5.1 ships

Apple published the release notes for App Store Connect API 4.5.1 (developer.apple.com/news/releases/?id=10062026a). They read the way these dot-release notes always read: a short enumeration of additions and fixes against app-management resources — the metadata, build, TestFlight, and reporting surfaces — with no identity, authentication, or signing contract in the list. It’s an incremental version bump on a REST API that exists to automate the boring parts of shipping software: app metadata, TestFlight builds, provisioning profiles, in-app purchase config, analytics pulls. CI runs it. Fastlane wraps it. Humans rarely touch it directly.

The annotation that matters for this desk: App Store Connect API is adjacent to identity in exactly two narrow places, and 4.5.1 moves neither of them.

The first is the bundleIdCapabilities resource — the thing that toggles whether a given App ID is allowed to use Sign in with Apple at all. Apple documents this resource and its endpoints in the App Store Connect API reference (developer.apple.com/documentation/appstoreconnectapi); the capability you’re looking for is the APPLE_ID_AUTH value of the BundleIdCapabilityType enum. You enable the capability on the identifier; the API can read and write that state. That’s a configuration surface, not a token surface. It decides whether the entitlement is legal, not how a credential is minted or verified.

The second is provisioning: certificates and profiles, the plumbing that lets a signed build install and run. Real security weight lives here — mishandle a distribution certificate’s private key and you’ve handed someone the ability to sign as you — but none of it is new in this build, and none of it is where your Sign in with Apple trust actually lives.

Both surfaces sat still. I checked the one that’s cheap to check. If you want to confirm your own App IDs still carry the capability they’re supposed to, it’s a single call against the documented /v1/bundleIds/{id}/bundleIdCapabilities endpoint:

1
2
3
4
5
6

# Confirm Sign in with Apple is still enabled on a bundle ID.
# $TOKEN is a short-lived ES256 JWT signed with your App Store Connect API key.
curl -s \
  -H "Authorization: Bearer ${TOKEN}" \
  "https://api.appstoreconnect.apple.com/v1/bundleIds/${BUNDLE_ID}/bundleIdCapabilities" \
  | jq '.data[] | select(.attributes.capabilityType=="APPLE_ID_AUTH")'

Empty result means the capability is off and your users are about to have a bad morning. A release note never tells you that. Your config drift does. 4.5.1 changed nothing about how this reads — which is the correct outcome and not a headline.

What a release like this would need to say to matter here

I keep a short list of phrases that pull an App Store Connect API note onto the identity beat. None appeared on October 6:

• Any change to the Sign in with Apple server endpoints — the /auth/token and /auth/revoke flows, the client-secret JWT contract, or the public keys at appleid.apple.com/auth/keys you use to verify an id_token. Those endpoints belong to the Sign in with Apple REST API, documented separately (developer.apple.com/documentation/signinwithapplerestapi), and don’t live in this API at all — which is the first reason to relax.
• Any change to App Attest or DeviceCheck assertion and attestation semantics. Unchanged.
• Any new signing or notarization requirement — a certificate algorithm deprecation, a profile-format change, a hard date after which old distribution certs stop validating. Nothing.
• Any touch to receipt validation or the App Store Server API’s signed-transaction format. Different API, also unchanged.

The release is a REST client talking to Apple’s app-management backend. The identity-critical material — the private key that signs your Sign in with Apple client secret, the Secure Enclave on the user’s device, the OIDC trust chain — sits in entirely separate systems that this version string does not reach. Treating the two as coupled is a category error, and it’s the error that makes people either panic at nothing or sleep through the one that counts.

October 8, 2026 — the deadline this release doesn’t mention

Here’s the beat that actually belongs on your calendar, and the reason I didn’t just send a one-line “pass” and move on.

Your Sign in with Apple client secret is a JWT you sign yourself. Apple spells out the whole contract on its “Generate and validate tokens” page in the Sign in with Apple REST API documentation (developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens): the header carries alg: ES256 and your kid; the claims set iss to your team ID, sub to your Services ID (the client ID), aud to https://appleid.apple.com, plus iat and exp. That same page is explicit that the token must be signed with ES256 and that exp must not exceed 15777000 seconds — six months — from iat. The .p8 key you sign it with doesn’t expire. The secret does. When it does, every server-to-server token exchange returns invalid_client, users can’t complete sign-in, and nothing in App Store Connect — not the portal, not this API, not the 4.5.1 release notes — sends you a warning the week before.

If you minted that secret by hand during integration and never automated the rotation, the expiry date is sitting in your codebase as a literal exp claim, counting down. Here’s the shape of the thing you should be generating on a schedule. Read it as illustrative, not copy-paste ready — JWT.signES256 is a stand-in for the step that does the real work, and in production that step is longer than one line: CryptoKit’s P256.Signing.PrivateKey.signature(for:) hands you a DER-encoded signature, and JWS wants the raw 64-byte r‖s concatenation, base64url-encoded, over the base64url-encoded header.claims input. The claims below, however, match Apple’s documented requirements exactly:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import Foundation
import CryptoKit
​
// Client secret for Sign in with Apple server-to-server calls.
// Claims per Apple's "Generate and validate tokens" documentation.
// Max lifetime Apple accepts: 15777000 seconds (6 months). Rotate well before exp.
// NOTE: JWT.signES256 is a placeholder — see note above on the real CryptoKit path.
func makeClientSecret(teamID: String,
                      clientID: String,   // your Services ID -> `sub`
                      keyID: String,
                      privateKey: P256.Signing.PrivateKey) throws -> String {
    let now = Date()
    let header = ["alg": "ES256", "kid": keyID]
    let claims: [String: Any] = [
        "iss": teamID,
        "iat": Int(now.timeIntervalSince1970),
        "exp": Int(now.addingTimeInterval(60 * 60 * 24 * 150).timeIntervalSince1970), // 150 days, under the 6-month ceiling
        "aud": "https://appleid.apple.com",
        "sub": clientID
    ]
    return try JWT.signES256(header: header, claims: claims, key: privateKey)
}

Set the lifetime short of the ceiling — 150 days, not 179 — so the rotation job has slack and a failed run doesn’t become an outage. Alert on the exp claim, not on a vendor email that isn’t coming. That’s the recurring dated beat that governs whether your sign-in works, and no App Store Connect API version — 4.5.1 or otherwise — participates in it.

Where this sits

4.5.1 is correct, boring tooling maintenance for the CI and release-automation beat. It earns no identity coverage because it changed no identity contract, and I’d rather say that plainly than manufacture a hook that six months of incident reports would make me regret.

Watch the other releases list for anything touching the server token endpoints, the App Store Server API’s signed payloads, App Attest, or a certificate deprecation with a hard cutover date. Those move this desk. Meanwhile the real countdown is already running in your own JWT. Go check the exp claim before something else does.