Problem Statement:
I want to solve the user authentication on Android applications using the FIDO2 protocol(by providing an SDK), without doing multiple registration ceremonies for different applications on the same device.
For example, If a user has been Registered(generated Public-Private key pair) in an Android application A, he/she shall not be required to Registered in an Android application B(Given App A and App B are on the same device).
What could be the possible Solutions(as per my knowledge):-
A common SDK integrated with application A and B to provide authentication.
Separate Authentication App.
I want to go forward with Solution 1 as Solution 2 might not be desirable because it needs an extra step of downloading an extra app(Authentication App).
What am I able to achieve right now:-
We are able to do passwordless authentication of a user for app A and app B by maintaining separate private keys for app A and app B .
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
During the registration step a Public-private key pair is generated by the authenticator.
PrivateKey_1(PrivateKey) gets created and is stored in the Keystore and PublicKey_1(PublicKey) gets created and is shared with the server.
Let's say now that User XYZ wants to login to the app B.
Same process gets repeated for user XYZ to register him with app B.
In this process, A PrivateKey_2 gets created and is stored in the Keystore and PublicKey_2 gets created and is shared with the server.
So in above scenario User XYZ is able to authenticate on App A and App B using private key PrivateKey_1 and PrivateKey_2 respectively.
I want to know the feasibility of the following Scenario?
I want to do passwordless authentication of user XYZ for app A and app B, where applications(app A and app B) can use the same credentials (public and private key pair ) and do not need to perform a repeated registration ceremony(creating public and private key) for the same user on the same device for multiple applications sharing the common SDK(app A and app B).
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
In this process, a PrivateKey_1 gets created and is stored in the Keystore and
PublicKey_1 gets created and is shared with the server.
User XYZ wants to login to the app B.
App B should be able to verify user XYZ using the previously generated
credentials(by app A).
Is this even possible? Is there any gap in my understanding?
Any Suggestion and help is really appreciable :) :)
FIDO2 credentials can be reused wherever the API is available so long as you reference the same RP ID whenever you attempt authentication. FIDO credentials are bound to a unique RP ID, and as long as you can prove ownership of an RP ID then you'll be able to request authentication with any credentials associated to that same RP ID.
In the case of Android, you'll be able to auth across apps so long as both apps are connected to a single website and its unique RP ID. To connect your app to a website, check out the FIDO2 API for Android docs, particularly its section on Interoperability with your website. It links to Google's page for setting up Digital Asset Links on your site so that you can prove ownership of an RP ID and use credentials associated with it for authentication across apps.
Once your apps and website are linked and the user has registered in one app you should then be able to use Fido2ApiClient.getSignPendingIntent() to authenticate in your second app so long as you specify your site's RP ID (the same one specified during registration) as the rpId in the PublicKeyCredentialRequestOptions you pass to the method.
P.S. What's nice about all of this is that credentials you register using Fido2ApiClient (or any equivalent API on other platforms for that matter) in a native app can later be used to log into your website using the WebAuthn API in the browser; you just need to reference the same RP ID in the PublicKeyCredentialRequestOptions you pass to WebAuthn's navigator.credentials.get()!
One of the main benefits of FIDO2 is that it prevents man-in-the-middle attacks where an attacker is trying to impersonate a genuine replying party. The FIDO2 key will only respond to the RP for which the private key is registered. Sharing authn across multiple RPs would break this model. I don't know what is possible on an Android device but I would have thought you would need some form of authentication broker (an IdP) which you auth to with the Key and it is responsible for proving auth to the apps.
Are these accounts registered on the same service? Reading the Android FIDO2 API Interoperability with your website section, it seems possible to host https://example.com/.well-known/assetlinks.json with multiple Android apps listed.
I saw your problem statement and I think you should use SAWO Labs API for solving the authentication part as it is very easy to use. You can use one API key in multiple applications to use the authentication and also this API has a trust feature where you have to authenticate from each application where the same API is used for one time and you will no longer need authentication every time. SAWO Labs API is a passwordless user authentication tool.
You can know more about the SAWO Labs API from the link given below:
https://sawolabs.com/
Related
I tried searching in various places, googling about how I can create and authenticate an SDK which I can use as a starting point. Here is what I am trying to achieve.
My Application:
I am creating a saas similar to firebase, supabase etc., where a user signs up on my application and adds some data, say a todo list.
Now, I would have to provide a client SDK(javascript) and server SDK(python, nodejs). Using this the customer should be able to add the SDK to his own application (Customer Application) and be able to access the data that My Application provides.
To do this, when the SDK is used in the Customer Application, I need to authenticate and get the user details, roles and provide the data from My Application. How can I do this?
I have seen that there is some kind of Client key and Server key generated in My Application. These keys can be used by the customer in his application and initialize the sdk using the Client key.
What kind of auth mechanism is this
How is the Client key and Server key generated securely
Any link/pointers to resources will be very helpful.
We use JWT based auth that encode certain Postgres user roles. You can find more information on it here: https://supabase.com/docs/guides/api#api-security
I need to develop an API using ASP.NET CORE 3.1 for an external company to update some subscription data.
This API is going to be used for a mobile app, and we are using a JWT bearer token to identify the users, so when a user logs in to the mobile app, we create a token and after that, all the methods of the API check the JWT to verify the user logged in. Until this, no problem and everything works just fine.
But we have an agreement with a external company to make some payments in their app, so we need to provide them an API method so everytime someone pays we can update our database. The problem is we have no control over this company app.
My question is, how can we protect that API method so we are sure only the calls from this external company app can get and update our database, but no one else can do it? A simple password?
Using VPN Tunnel it is running securely between to parties as if it was running lan.
strongSwan is a complete IPsec solution providing encryption and authentication to servers and clients.
It can be used to secure communications with remote networks, so that connecting remotely is the same as
connecting locally.
StrongSwan is one of the solutions, many other products can do the same.
https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan
I am trying out a sample hyperledger fabric app. I am thinking to develop a web app that can communicate with fabric chaincode and execute chaincode functions. But inorder to uniquely identify a user, the certificate is required. How can I achieve a user login mechanism in my web app (for example with username, password) such that it will identify the user who logged in and is calling the function.
Hello #Mohamed Noushad
It is very simple
As we know once we register a user and enroll we will get a private key and a certificate to us. It will be difficult to manage the keys by the users
So, traditional users are more comfortable with usernames and passwords rather thank keys. So, Create a database on top of user keys. username, user
user is for fabric and username is for your database. Or you can use the username for both
You handle the keys and the user needs to authenticate to prove that the set of keys belongs to him. Once the user authenticates with creds in the database using a normal username and password then you allow him to interact with fabric with the key enabled by you on behalf of the user.
Certificates can be stored in three different ways
local kvs (file system)
couch dB kvs
Hardware wallets (HSM)
This is just one suggestion. We can do (n) No of ways. just think!!
How / can I get Google cross-client auth to work in a client-type-agnostic way (e.g., using only a web browser and cURL commands)?
I have two OAuth 2.0 clients (let's call them Client A and Client B), both of type "Web Application" and in the same Google API Console project. Each client's credentials is used by a different app (say, Apps A & B, respectively):
App A implements Google Sign-In using Client A; the ID token obtained after a user signs in is sent to a /verify endpoint, which verifies the token and authenticates the user to the app.
App B wants to automate the offline authentication of a specific user to App A by sending an ID token (obtained using Client B's credentials) directly to its /verify endpoint. (Note that App B doesn't have access to Client A's secret.) The general strategy is:
manually get a one-time-use auth code for the user (using proper scopes and access_type=offline),
exchange it for tokens (requires client secret),
securely store the refresh token and use it to generate ID tokens whenever I want, which I'll in turn use to authenticate the user to App A.
If App B uses tokens obtained in the "normal" way using Client B credentials, then App A will see my ID token as invalid, since the standard check involves verifying that the decoded token's payload has an aud value equal to Client A's ID, which it won't.
Cross-client identity/auth to the rescue, right?
From https://developers.google.com/identity/protocols/CrossClientAuth:
Google considers that when a user has granted access to a particular scope to any client ID in a project, the grant indicates the user's trust in the whole application for that scope.
The effect is that the user should not be prompted to approve access to any resource more than once for the same logical application, whenever the components of the application can be reliably authenticated by Google's authorization infrastructure, which today includes web clients, JavaScript clients, and Android apps.
(Emphasis mine.)
The Problem
The problem is that, while the docs explicitly say that what I want to do is possible, it only shows an example for Android -> Web cross-client auth, which involves calling a specific utility function available only on Android, passing the scope as a "magic string" of the form oauth2:server:client_id:{CLIENT_A_ID}:api_scope:{SCOPE1 SCOPE2 ...}.
I've scoured the internet and have found zero examples of how to do this in a generic way or for other client combinations. I've tried naively sending a similarly-constructed "magic" scope string when requesting an auth code, which is seen as an invalid by Google's servers (invalid_scope 400 error). I've stopped just short of decompiling Google libraries to see how it translates this string into actual server requests (if that's, in fact, what it's doing).
My question: Does anyone know how to get Google cross-client auth to work in a client-type-agnostic way? (Or at least in the specific way I'm asking?)
I've successfully built a ruby script and a mac app that use service account credentials to authenticate (without user interaction) to google cloud storage and upload/download objects.
I now need to perform similar actions on an iOS device. Is it possible to use installed application credentials to authenticate still without user interaction?
If it's possible or has been done, can you please provide an example or point me in the right direction.
Thanks!
You need the private key for the service account to get the access token for the application. Please bear in mind that some hacker may steal that private key for both mac and iOS app. If the data is per user and you have a backend server, you may authenticate the user on the backend and then use the private key on the server to access the storage. If the data is per app, seems there is no good way to prevent the private key abuse.