1

Currently we are looking into the development of a mobile app (native) and we would like to login the customer to the backend (Java) which has a REST API using a 5 digit code, their fingerprint or face ID only. Now did I read the RFC 8252 (https://www.rfc-editor.org/rfc/rfc8252) which stated that this is the best authorization method for native mobile apps, but I was wondering how the authentication step should work in this case. Of course I already found a few topics on stackoverflow but most of them are quite old and probably outdated (?), e.g. Rails api and native mobile app authentication

I expect that it should work as follow, but not sure if that is correct. When the customer register in the mobile app, we should generate a token (UUID) in the backend and store this in the database in the keychain of the mobile app which can only be accessed by entering the PIN or biometrics. When the customers authenticate their self via either the PIN of biometrics we could grap the token and sent this to the backend to verify if it is valid. Only I have a few concerns about this approach:

  • As we will only authenticate the customer based on the token this would mean that if you can grap the token, you can login on each device. To avoid this we could store the device ID or another ID that makes the device unique, although from a GDPR perspective it's not ideal to store the Device ID as you can identify the customer based on this ID.

  • If the customer will root the device they have access to the keychain and thus the could grap/steal the token

So as you understand I'm not sure if this is the most save approach and I was wondering if there are better practices to create an authentication/authorization flow for a native mobile app, e.g. how are mobile bank apps doing their authentication/authorization flow?

Thank you

Community
  • 1
  • 1
Danny Gloudemans
  • 2,597
  • 7
  • 39
  • 57
  • On iOS, at least, the device identifier you get is unique to your app on that device, so there should not be any GDPR implications as you cannot use it to identify them outside of the scope of your app. When the customer registers do they create a username and password? If so, why not just store those credentials in the keychain secured by biometrics? Why make some other token? You have tagged OAuth which implies that you want authentication beyond just the app. – Paulw11 Jul 22 '18 at 21:33
  • Thank you for your comment @Paulw11. You stated that each app has it's own device identifier (UDID), but I believe that the UDID is unique to the device and not to the app itself or is the variable that you're talking about another thing? Regards the registration flow, the customer won't setup an username, only a password that consist of digits, but that could we store in the keychain as well. The only question is if that is secure enough, because when the device has been rooted or jailbreaked anyone can enter the keychain I believe. – Danny Gloudemans Jul 23 '18 at 07:26
  • 1
    Apps can no longer access the UDID. You can only access `identifierForVendor`. This will provide a unique id for your apps on a given device (i.e. if you have two apps on the same device both will get the same `identifierForVendor` value). – Paulw11 Jul 23 '18 at 07:37
  • It isn't exactly true that "anyone" can get values out of the keychain; You need to have physical access to the device, so presumably this is the device owner. You cannot protect against malicious acts by anyone who has physical access to a device and the passcode for it. Jailbreaking is pretty rare on iOS; my guess is that less than 0.1% of owners would jailbreak their devices, possibly even less. Remember that many users will have multiple devices and expect to be able to access their account from all of their devices. – Paulw11 Jul 23 '18 at 07:38

0 Answers0