I’m trying to get DeviceCheck to work, where I keep getting this response from Apple’s server: 401 ‘Unable to verify authorization token’.The device_token is being sent to my Python server over a base64 encoded string in another similar JSON payload. I’ve even tried cutting and pasting the base64 string from the logs directly to my server (very quickly) and nothing works. Any ideas what I might be doing wrong?I’m slightly concerned perplexed that in the https://developer.apple.com/account/ios/authkey/, the generated key is not explicitly associated with my app other than being generated in my apple account.def device_check_query(device_token): data = { ‘device_token’: device_token.replace(“\\“, “”), ‘transaction_id’: str(uuid4()), ‘timestamp’: int(time.time() * 1000), } jw_token = get_jw_token() headers = {‘Authorization’: ‘Bearer ’ + jw_token} response = requests.post(QUERY_URL, json=data, headers=headers) return response.content def get_jw_token(): with open(KEY_FILE, ‘r’) as cert_file: certificate = cert_file.read() jw_token = jwt.encode( {‘iss’: TEAM_ID}, certificate, algorithm=‘ES256’, headers={‘kid’: KEY_ID}) return jw_token

I am trying to generate DeviceCheck token with DCDevice.current.generateToken. There was no problem at first, but after a few days, it started to give the error below:The operation couldn’t be completed. (com.apple.devicecheck.error error 0.)Interesting point is that, the problem starts and ends at the same time on all devices, at random time periods of the day. My question are;* What "Error 0" means?* I thought generateToken method generates the token in the device offline, but it seems not (by starting to give error on generateToken simultaneously on all devices), can you give some details on how generateToken works?* Do you have any comments on starting to get "Error 0" on all devices at the same time?Thanks.

I have built a server app to generate a JWT using apple KEYID, TEAMID and P8 private key file. I am submitting the JWT with required payload to https://api.development.devicecheck.apple.com/v1/query_two_bits. However Apple's development devicecheck server always returns http response 401 - Unable to verify authorization token. Is there some other request I can send to Apple's development devicecheck server that could give me more detail why error 401 was being returned?

I am submitting the JWT with required payload to https://api.development.devicecheck.apple.com/v1/validate_device_token. However Apple's development devicecheck server always returns http response 401 - Unable to verify authorization token.  I generated the token following the instructions in https://developer.apple.com/documentation/appstoreconnectapi/generating_tokens_for_api_requests and check token by curl -v -H 'Authorization: Bearer [signed token]' "https://api.appstoreconnect.apple.com/v1/apps" I can use that token to call this API successfully. However, when I tried to use exactly the same token to verify a device ID, I got a 401 response here is my payload for the request https://api.devicecheck.apple.com/v1/validate_device_token It's my code: now = int(time.time()) expire_time = now + 20 * 60 HEADERS = { 		"alg": "ES256", 		"kid": kid, 		"typ": "JWT" } PAYLOAD = { 		'exp': expire_time, 		'iss': iss, 		'aud': "appstoreconnect-v1" } jwt_token = jwt.encode(PAYLOAD, private_key, algorithm='ES256', headers=HEADERS).decode('utf-8') auth = 'Bearer {}'.format(jwt_token) headers = { 		'Content-Type': 'application/x-www-form-urlencoded', 		'Authorization': auth } response = requests.get( 		'https://api.appstoreconnect.apple.com/v1/apps', 		headers=headers ) print(response.status_code) print(response.text) request_file = '.../ValidateDeviceTokenRequest.json' data = None with open(request_file) as json_file: 		data = json.load(json_file) data['timestamp'] = (now) * 1000 response = requests.post( 		'https://api.devicecheck.apple.com/v1/validate_device_token', 		data=json.dumps(data).encode(), 		headers=headers ) print(response.status_code) print(response.text)

Hello, I have problem with DeviceCheck framework on iOS 14. On some devices with version, 14.x attestation doesn't work properly. In response, I get 400 error code and Missing or incorrectly formatted device token payload. This is very weird because this reproduces on a small group of devices and device after hard reset works fine.

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.

We see appAttest (available iOS 14+) provides us 3 key features: if app instance is not modified, device is genuine apple device and payload is not tempered with. We also have deviceCheck Api (iOS 11+) which return 2 bits per device, as mentioned in documentation we can create different payloads for validation and different for updating the 2 bits. Apart from returning those bits in validation request, does this DeviceCheck APIs also validate 2 of the 3 above features i.e. app is not modified and the device is genuine apple device? If yes, what response from apple server to look for in successful validation of above 2 features and what response to look for in fraud cases or failure cases? Does isSupported in case of DCDevice.current hints the device is a simulator ? Can we get exhaustive list of cases where isSupported is false? Does DCDevice.current.generateToken fails only in case of modified app instance? Can we get exhaustive list of cases where above can throw error? Can modified app instance also able to generateToken?

According to the App Check Firebase Documentation, it is said to add the App Attest capability to your app. However, I am not able to find any such capability in XCode. Any insights on this? Note: We have enabled capability in the provision profiles Documentation Link: https://firebase.google.com/docs/app-check/ios/app-attest-provider#install-sdk

Hello guys, Me and my team are developing an application which uses some data from an API and we need to verify that we can recognize a single user ID of the iOS phone to establish a univocal trust relation to share keys that would help us encrypt the communications. I tried some pieces on code that I found on internet, but I do not know if this is enough. print("ID Vendor...\(String(describing: uiDevice.identifierForVendor))") print("iCloud token...\(String(describing: FileManager.default.ubiquityIdentityToken?.description))") And also I was trying to work with DeviceCheck framework and to get that token. print("Generate token")                 DCDevice.current.generateToken {                 (data, error) in                 guard let data = data else {                     return                 }                 let token = data.base64EncodedString()                     print("Token...\(token)") What I want to do is to verify the user identity something like the Apple ID or some personal data, not the device information. Is there a way of retrieving some personal data from the owner of the iPhone that I can use to check if he is who said that it is? Thank you so much! Have a good day!

Hi, We have a multi-platform application that requires integrity attestation before the backend will enable supporting services (fairly common scenario). I've read the documentation for DeviceCheck and AppAttest, as well as SafetyNet on the Android side. The Android documentation includes lots of examples of use, including server-side (though oddly in C# and Javascript... which I don't see as being server-side languages, but... oh, well). Anyway, maybe there's a server-side example of using an application attestation on the server when validating a client, as well as validating individual requests with assertions, but I've not been able to find it. It seems like a relatively important bit of functionality to ensure that apps aren't being compromised, while at the same time requiring a correct implementation... Why not give a reference implementation as a starting point to make sure developers are on the right path? Can anyone point me at an example as a Gist, etc? Thanks.

I'm looking at a development attestation for an app we're developing in-house, and there's a couple of undocumented PEN's being used: Certificate:     Data:         Version: 3 (0x2)         Serial Number: 1631564652467 (0x17be0d4dfb3)         Signature Algorithm: ecdsa-with-SHA256         Issuer: CN = Apple App Attestation CA 1, O = Apple Inc., ST = California         Validity             Not Before: Sep 12 20:24:12 2021 GMT             Not After : Sep 15 20:24:12 2021 GMT         Subject: CN = a203e1588ab36ae2ffc362491c2948df5d03f3ed048d0c58a59c9e085724353c, OU = AAA Certification, O = Apple Inc., ST = California         Subject Public Key Info:             Public Key Algorithm: id-ecPublicKey                 Public-Key: (256 bit)                 pub:                     04:09:1a:ae:9f:d2:0b:89:e6:6b:ab:68:3e:70:e1:                     6d:0f:b1:2f:8b:4b:bd:c9:d2:54:ec:15:2c:b4:fc:                     4c:8d:fb:e1:49:0d:90:34:80:10:82:08:6c:49:58:                     7e:2c:5b:90:2b:80:2d:1f:f3:e9:36:59:51:d2:3e:                     1d:d2:f8:75:e3                 ASN1 OID: prime256v1                 NIST CURVE: P-256         X509v3 extensions:             X509v3 Basic Constraints: critical                 CA:FALSE             X509v3 Key Usage: critical                 Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment             1.2.840.113635.100.8.5:      0:d=0  hl=2 l= 111 cons: SEQUENCE               2:d=1  hl=2 l=   3 cons:  cont [ 4 ]             4:d=2  hl=2 l=   1 prim:   INTEGER           :0A     7:d=1  hl=4 l=   3 cons:  cont [ 1200 ]         11:d=2  hl=2 l=   1 prim:   INTEGER           :01    14:d=1  hl=4 l=   3 cons:  cont [ 1201 ]         18:d=2  hl=2 l=   1 prim:   INTEGER           :00    21:d=1  hl=4 l=   3 cons:  cont [ 1202 ]         25:d=2  hl=2 l=   1 prim:   INTEGER           :01    28:d=1  hl=4 l=   3 cons:  cont [ 1203 ]         32:d=2  hl=2 l=   1 prim:   INTEGER           :01    35:d=1  hl=4 l=  38 cons:  cont [ 1204 ]         39:d=2  hl=2 l=  36 prim:   OCTET STRING      :XKXEK7P8ZU.com.truepic.appattestdemo    77:d=1  hl=2 l=   6 cons:  cont [ 5 ]            79:d=2  hl=2 l=   4 prim:   OCTET STRING      :sks     85:d=1  hl=4 l=   3 cons:  cont [ 1206 ]         89:d=2  hl=2 l=   1 prim:   INTEGER           :05    92:d=1  hl=4 l=   3 cons:  cont [ 1207 ]         96:d=2  hl=2 l=   1 prim:   INTEGER           :00    99:d=1  hl=4 l=   3 cons:  cont [ 1209 ]        103:d=2  hl=2 l=   1 prim:   INTEGER           :00   106:d=1  hl=4 l=   3 cons:  cont [ 1210 ]        110:d=2  hl=2 l=   1 prim:   INTEGER           :00             1.2.840.113635.100.8.7:      0:d=0  hl=2 l=   6 cons: SEQUENCE               2:d=1  hl=4 l=   2 cons:  cont [ 1400 ]          6:d=2  hl=2 l=   0 prim:   OCTET STRING                   1.2.840.113635.100.8.2:      0:d=0  hl=2 l=  36 cons: SEQUENCE               2:d=1  hl=2 l=  34 cons:  cont [ 1 ]             4:d=2  hl=2 l=  32 prim:   OCTET STRING             0000 - 52 93 c9 c6 69 4e 74 3c-63 13 4b d0 0a 92 12 87   R...iNt<c.K.....       0010 - 36 64 cf c3 3d 8d c0 5b-3b 26 72 5a a4 5a ab 71   6d..=..[;&rZ.Z.q     Signature Algorithm: ecdsa-with-SHA256          30:65:02:31:00:d0:40:c9:18:68:10:c7:0d:2a:04:31:9a:38:          74:7a:ee:1e:a3:da:a3:58:05:0f:15:ae:86:9e:19:07:b8:d3:          67:fc:c1:3f:e4:c2:eb:1b:37:d5:b1:c3:6f:df:52:da:c0:02:          30:5b:8e:d8:67:9e:5d:59:64:68:bf:85:a8:a7:ae:e8:a8:e4:          06:f0:df:75:c5:e8:7e:0a:d4:24:64:e8:6c:c3:2d:ac:31:bf:          3f:d1:78:a7:00:ff:11:31:1b:28:08:27:5d .2 I get. It's documented in Validating Apps That Connect to Your Server. Some GitHub gists suggest that .7 is supposed to be an Octet String containing the iOS version number, but it's empty in our case. Unclear why. No idea what .5 is supposed to be. Does anyone have any insight into these last two? Also, how does one determine the particular that's generating the attestation? Android SafetyNet attestation generates a unique hash (as the list of SHA256's in apkCertificateDigestSha256); it seems to me that we might want to further fine-tune the handling of sensitive operations based on the specifics of the version. Lastly, the above cited documentation states, in the "Store the Public Key and Receipt" section: Store the verified public key from credCert on your server and associate it with the user for the specific device. You use this key to check assertions later. But iOS (and iPadOS) doesn't support multiple accounts per device. So I'm interpreting this to not refer to an associated AppleID, but rather credentials in some app-specific space defined by the app developer. Is that correct? Thanks

I'm testing with a simulator and isSupported is returning True..

Hello, I am sending valid base64 receipt data to Apple on the https://data-development.appattest.apple.com/v1/attestationData endpoint and am getting 400 bad request. I have a valid JWT that I currently use successfully for other DeviceCheck endpoints such as persistent bits. Any help debugging would be useful. Thanks

Hi! We are using Device Check tokens to prove that HTTP request comes from iOS device. We found out that both envs - prod and sandbox doesn't limit token lifetime v1/validate_device_token always return true and can be reused for a long period of time per one DCDevice token. v1/update_two_bits also can be reused unlimited number of times per one token (didn't measure the exact number) Is it true - that lifetime of token generated via DCDevice.generateToken isn't short (minutes) and we should build our own infrastructure to prevent replay attacks?

I have a webserver developed from scratch in Microsoft visual c ++ 2019. I use only c/c++, when I receive the request, I process it and build a response that I send to the client. I use my iPhone (13 pro with iOS 15.2). Case 1: I am connected to a local wi-fi, I type the server address (local address or external address by port forwarding), it receives 'get / http ...' and 'get / other resources' through 3-4 simultaneous connections and responds with the content of the requested page. The connections remain stable and I can navigate further through the site, opening other pages without any problems. iPhone send requests and my server respond. everything works fine. Case 2: I am connected only to the telephone operator (4G Vodafone), I type the external server address, it receives 'get / http ...' and 'get / other resources' through 3-4 simultaneous connections and responds with the content of the requested page. (just once, only first page). After that, the connections disappear and I can no longer browse the site (because I lose the session ID and other credentials). **In fact, the iPhone, after receiving what it requested, sends many null buffers and my server disconnects all sockets immediately. is something to do with WSAENOBUF, but I don't know what.   ** Why this dual behavior. How can I solve this situation? Thank you very much.

Always get this error during device token validation. Are there any ideas why it's happening? Here is the snipped of the code below I use for JWT generation. import time import jwt private_key = """-----BEGIN PRIVATE KEY----- mykey -----END PRIVATE KEY-----""" data = { "iss": "my_team_id", "iat": int(time.time()), } headers = { "kid": "my_key_id", } jwt_token = jwt.encode( payload=data, key=private_key, algorithm="ES256", headers=headers ) print(jwt_token)

Hi! Sometimes when calling DCAppAttestService.shared.generateAssertion(key.id, clientDataHash: hash) I'm getting DCError.Code.invalidInput. I am formatting clientDataHash usingSHA256.hash - so it is always 32 bytes long. As I found out - this error depends on hash that I pass to generateAssertion method. But I could not find any system - which hashes are good and which are not. Keys are always correct, otherwise invalidKey error would be risen. What can cause the issue? I'm testing on iPhone 11, iOS 15.2.1

Hi, I'm trying to validate device token generated on app which is signed by Enterprise account. I generate deviceToken on device I send the token to our backend Our backend creates JWT token The backend calls validate_device_token endpoint and receives 401 The authentication token can't be verified I've seen many implementations on the internet and I'm pretty sure that we generate the token in correct way. (eg implementation: https://github.com/marinosoftware/DeviceCheckSample) The Questions are: Is it possible to use DeviceCheck on Enterprise Account ? There is no possibility to enable DeviceCheck on Enterprise account is APNs key configuration: https://developer.apple.com/account/resources/authkeys/list. Is this configuration required ? Is there is a way to validate signature of JWT token locally ? Services such as https://jwt.io requires Public and Private keys in correct format, I didn't find a way to validate the signature signed by p8 certificate without any additional keys.

Apple team, I need your help. Can you answer for my question in thread: https://developer.apple.com/forums/thread/701876 ? I created new thread due to I wasn't able to add tag wwdc21-10244 in thread 701876.

Is there a recommended way to determine whether to use the development or the production server API endpoint for DeviceCheck? For App Attest, the authenticator data includes either "appattest" or "appattestdevelop" in a field of the cbor data. For IAPs, we're supposed to try the production endpoint and then retry with the development endpoint if we get a particular HTTP status code. But the docs for DeviceCheck say only to use the development endpoint in development and the production endpoint in production. What are others doing? Is there any clue in the docs that I have missed?