Open crspybits opened 3 years ago
Actually I think the reverse is true. The spec for DPoP says:
Native applications installed and run on a user's device, which often have dedicated protected storage for cryptographic keys are another example well positioned to benefit from DPoP-bound tokens to guard against misuse of tokens by a compromised or malicious resource.
The public and private keys are generated by the app rather than coded in. The public key is sent to the authorising server which returns an access token which is bound to the public key - the token can only be used by a client possessing the private key. A different DPoP is generated for each request.
That is very good to know. It won't be useful for me right now, but I'll look into how public/private keys can be generated in an iOS app. Thanks!
Some references:
https://stackoverflow.com/questions/31911821/creating-ssl-public-and-private-key-pair-in-ios-app
https://developer.apple.com/forums/thread/85914
https://stackoverflow.com/questions/33021946/generate-an-rsa-public-private-key-pair
https://stackoverflow.com/questions/24291264/ios-app-data-encryption-with-public-private-keys
Wow. I definitely learned something new today! :)
SolidAuthSwift uses a public/private key pair to generate DPoP's (https://solid.github.io/solid-oidc/primer/). It seems like a bad idea to store these on a mobile client. They would presumably have to be static and built into the app. As I understand it, apps can be decompiled when phones are jail broken and this could break security. Thus, it seems like an iPhone app using SolidAuthSwift necessarily has to have a custom server if it wants to access resources on a Solid Server (e.g., files).
This happens to be the exactly use case I'm designing for for SyncServer/Neebla (e.g., https://github.com/SyncServerII/Neebla, https://github.com/SyncServerII/ServerMain), but not all iOS apps want to or need to use a custom server.