I'm developing a web app using ASP MVC 5 and Identity for user authentication. The users have some devices that I'm going to sell them. In the web app I can manage devices, setting device's serial number, customer (web users) and other information.
These devices have to download content related with the customer. I don't know if it is good idea to save customer's username and password in the device (app code or configuration file,...). So I thought that using device's serial number would be a good choice to authenticate the device.
So, is there any way to develop a Wep API service using the serial number or something similar to authentication process?
Related
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/
So I have this really old UWP app that has been using the Live/OneDrive SDK to provide authentication and identification for at least 7 years now. The app is registered with Microsoft Account Authentication which provides a Client Id and Client Secret to identify the app when an authentication request is made.
When I use the SDK for authentication (OnlineIdAuthenticationProvider), it returns a unique Id (CurrentAccountSession.UserId) with which I can determine which of my users is using the app and then use that unique Id to persist/retrieve information the user provides.
The problem is....The OneDrive SDK is super old (hasn't been touched in over 3 years), outdated (.NET 4.51...no .NetStandard implementation) and Microsoft is pushing everyone to use MSAL and Graph instead. Fine.
But how can I do that and still be able to tie the person who is logged in to the app to the information I am storing for her/him?
From what I'm seeing, in order to use the new SDKs, I have to register my app, again, in the Azure portal and use a new Application (client) ID. If so, when my user logs in...my expectation is that any identifier that's returned to my app in the authentication process will not be the same as the UserId I've been using for almost a decade.
Has anyone done this? I can't be the only person who has encountered this problem...can I?
Any help would be greatly appreciated....
Here is what I want to do.
I want to have a MVC web application that I can user to administer tables in my SQL server database (windows azure). I want to authenticate with a 3rd party login (google, twitter, facebook etc).
I want to have a mobile application that makes use of windows azure mobile services to access and modify those tables. The mobile app will log in with the same providers as above.
The problem: when I log in with the MVC application I have access to the username and email address.
When I log in with the mobile application I get access to a userId ="google":{
"userId":"Google:my-actual-user-id",
"accessToken":"the-actual-access-token"
}
on the mobile service side but not the email address or username.
So if I want to write a Server side script(azure mobile service) to get data from the tables, what should I use as the unique user identifier?? The MVC application does not have access to the userid the mobile application gets on login, and the mobile application does not have access to the username or email address available via the MVC login(OAuthWebSecurity)
I found this link: http://blogs.msdn.com/b/carlosfigueira/archive/2012/10/25/getting-user-information-on-azure-mobile-services.aspx
But looks like you cannot even get the google email using this…. So still no way to uniquely identify the user!!
Thanks for any help
It doesnt really answer how to get around the issues highlighted above. I imagine using the same type of authentication in my MVC application would have got around this, but then I would have to have found a way to get the email address for a google account. Then I would have had to consider how to handle other authentication providers which would have brought other issues. I found other issues with windows azure mobile services which meant it just wasnt for me
Does not seem to be a way of accessing data from a different database namespace with mobile services
I was re-writing business logic in the mobile service that I already had in my MVC application, which I had unit tested, with entity framework etc
It seems simple and straight forward if you follow the examples of mobile services but once you step off that track it becomes very problematic and in my view just not worth it. It is not flexible enough to do anything meaningful.... but that just might be me not using it correctly.
So I am now using web api within my MVC application. Using httpclient in my windows app to contact access this data. It allows me to reuse my business logic, and it is much more flexible. If you feel the assessment of windows azure mobile services (chocolate tea pot) is unfair would love to hear an opposing view.
I have two separate apps and one Azure Mobile Service. Is there a way to link both apps to use Live Connection through the same Azure Mobile Service. The service allows associating one app to my Azure Mobile Service domain, but when I try to associate another app to the same service, I get an error that it is already in use (which is correct, but intended!).
One Azure Mobile Service
2x Different Client Apps
Live Auth
Is there a way around this or am I forced to create a new mobile service for each app client type I have. This seems silly as they're all using the same back end service.
This is not currently possible. If you look at the Identity settings for a Microsoft Account, one of the requirements is the Client ID which is tied to each individual Windows 8 app ID.
I'm currently planning a new web project. Clients are going to connect using a regular web browser and, in case of regular java-enabled cell phones, j2me client. I would really like to make use of the OpenID authentication. In case of regular web browser things are pretty straightforward. However, I am really not sure about installed applications (such as j2me client installed on a mobile device) - regular OpenID authentication is performed by entering username/password on a webpage of particular OpenID provider - which is quite a limitation :)
Has anyone coped with such a situation? Is it possible to create authentication mechanism to the site that uses OpenID from a mobile j2me client?
Currently, I think of solution that users who would like to connect from their mobiles download necessary j2me application from the server web site after they have authenticated themselves (regular browser authentication). The mobile client app could be assembled dynamically on the server with the SSL certificate embedded that is associated with particular logged in OpenID user. After that, j2me client could authenticate to the server without entering any username/password. The data that is going to be stored on the server is not THAT sensitive - considering cases of mobile phone thefts etc.
Can anybody come up with a better solution?
The best solution IMO for what you're doing is to use OAuth combined with OpenID. You're use of OpenID at the RP is fine. But for installed applications that need access to that web site, they should use OAuth to get authorized. The flow would work like this:
User installs app on their device
During install or on first launch, the app has an "Authorize me" button.
The user presses the button and a web browser pops up the web site that the client app needs to access data from.
User logs into that site using their OpenID
Site now asks "do you want to authorize client app X?"
User says yes and closes the browser.
The client app reappears and says "thanks." and now has the OAuth token necessary to access the user's data without the user ever logging in again.