I want to use Worklight application authenticity in an Android Native Application. I have already configured my customsecuritytest and I have included the libraries that I need into my android project. The problem appears when I need to export the public signing key. I know how to do it in a hybrid application, you just need to right click over the android environment. But what about the native API project? How can I get the key?
The user experience is not great here. At all.
I've created a defect to correct this.
To add the public signing key, you need to use same public signing key as you would for a Hybrid application. This includes following the same steps. Meaning, create a Hybrid application with the Android environment, generate the public signing key and copy it over to the Native API's application-descriptor.xml.
Basically, do over slide #17 from the Application Authenticity Protection training module.
Related
Background of the issue:
The project has microservice architecture and using APISIX as API gateway.
APISIX jwt-auth plugin is used for user authentication from gateway side. Recently we stared using google identity platform for user management and authentication so the jwt tokens will be created by google and we need to verify the token using their public keys published in the url.
As per the google documentation we need to refresh the public key after certain amount of time.
When coming to the apisix part there is no option for refreshing the public key dynamically also there is no option to save multiple public keys in jwt-auth plugin.
Please let me know how we can achieve this scenario.
I am working on an android and iOS application that needs to have a password-less solution for login. We are trying to implement WebAuthn/Fido2 device.
The problem is that Fido is still new and there is no React-Native library that implements that. So I have a few questions regarding it.
Can we read and write our own key in the Fido2 device?
=> Till we get a proper library, I want to store an encrypted password on the fido2 device as a key, read it every time on login, and decrypt it. Is it sounds good to implement and is it possible to do?
#DevPy
To support WebAuthn/FIDO2 from your React Native iOS application, the recommended solution is to integrate one of two Apple iOS system browsers (ASWebAuthenticationSession or SFSafariViewController) that support WebAuthn APIs. ASWebAuthenticationSession would be my first choice as this browser is for authentication through a web service, specifically the OAuth 2 flow. This provides the interface, built-in APIs for interacting with the FIDO2 authenticator, like the YubiKey, and gives the developer control with callback to the session and authentication token. Another way to integrate WebAuthn is to utilize a third-party SDK for communicating with OAuth 2 providers. For example, AppAuth for iOS has a React Native bridge, available here. I believe the AppAuth SDK uses the ASWebAuthenticationSession.
As for the initial question of writing/reading your own custom key, the FIDO2 devices are limited in storage space but the YubiKey offers two options that may work for you. One is the option to create a static password (not encrypted) or utilize the Yubico OTP. Both options use the system keyboard to type out the password or OTP into any text/password field within your app. No SDK or system browser required.
FIDO2/WebAuthn is specifically a browser API. Since you're talking about authentication within a (React) native app then you'll probably want to fall back to equivalent native OS API's instead.
For Android you can use the Fido2ApiClient, which will let you leverage existing FIDO2 credentials on your server for in-app authentication:
https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/Fido2ApiClient
I think the equivalent on the iOS side of native app development is Authentication Service. They have a page specifically about leveraging "passkeys" in your app that will probably help get you started:
https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication
Is there another way to implement the Google Drive API instead of using the keytool to get the keystore sha1 and insert it into the Play Console credentials page? I'll use the APK outside the Play Store.
Based from the documentation, the overall process of making a Drive-enabled Android application is as follows:
Install the Android SDK.
Download and configure the Google Play services SDK, which includes the Google Drive Android API.
Register your application. To do this, you need to register a project in the Google API Console and get a signing certificate for
your app.
Add the required settings to your application's manifest.
Add Drive services to your application. The easiest way to begin is by creating a file.
There's no another way to implement Google Drive Android API other than the above steps. From step 3, you must register your application with the API console and run the KeyTool utility to get the SHA1 fingerprint for your digitally singed .apk file's public certificate. Then paste the SHA1 to the credential page in the API console.
WL.Client.InvokeProcedure is an internal API and used by Worklight Framework, however, you can call this API after connecting a device in Debug mode with Google Chrome. How can we restrict the access to WL.Client.invokeProcedure so that a user is not able to Exploit this call?
Steps to replicate (for Exploitation Only):
1. unpack an APK built by Worklight
2. Set the android:debuggable=true (also check how WL Adapters are being called in JS files)
3. Rebuild the APK
4. Install the APK in mobile
5. Start the Application and connect through Chrome://inspect
6. Authenticate as a "normal" user
7. Go to Developer Console
8. Invoke WL.Client.invokeProcedure for any adapter you are authenticated, but with unauthorized User Data
I think the test is a bit misleading since "you" as an attacker will have several prerequisites: have the technical skill of manipulate code, invoking code and know what is a "normal" user.
That said:
In the upcoming MobileFirst Platform v7.0 you will be able to obfuscate the code of a mobile app (iOS, Android and so on). You can also do this manually now.
Already now you can enable the Application Authenticity Protection feature as well as the webResourcesChecksumTest and webResourcesEncryption features. See the security element section in the Application Descriptor user documentation topic.
The above will add several layers of protection to your application, either preventing tampering with the application code, not allowing to use the app if its checksum has change and verify the application identity.
I'm just getting started porting my old code over to the new google apps json service but I'm not clear on the oauth.
I'm looking at:
https://developers.google.com/admin-sdk/directory/v1/guides/prerequisites
It says:
"Set up a new project in the Google APIs Console and activate Admin SDK service for this project. See the Google APIs Console Help in the upper right corner of the Console page for more information about creating your API project. "
My product gets installed at each client location. Do I create the app using my key then distribute this to my customers or do I use their key in my app that runs at their site? Do I also need to enable the admin SDK in addition to enabling API access?
Do I create the app using my key then distribute this to my customers or do I use their key in my app that runs at their site?
Do they have access to the source code? If true then it will be known to them.
Whether it is your key (an API project owner by you) or theirs depends on the kind of software you offer (tailored or common service (webapp?)) and who will be responsible of the quotas, billing (if needed) and maintenance.
Do I also need to enable the admin SDK in addition to enabling API access?
Yes.
FYI:
API projects can hold up to 20 accounts
Users can own several projects (don't know how many)
Projects can be shared with other users or Groups