I'm building a Windows 8.1 store app and need to incorporate authentication. This is an enterprise app used in house. We load the app onto a tablet and a team may check that tablet out for weeks at a time, go out to the field to collect data and then we put in on a shelf until another team needs to use it. Now different teams may work for difference clients so when we authenticate users not only do they get access to the app but we also check what groups they are in to determine what clients they can work on or what previous records they can search for.
I've followed various ADAL tutorials and am able to setup everything in Azure and in my app I am able to authenticate a user successfully and get their groups. This relies on ADAL handling the username/password. What happens when the app shuts down and the user in a place where there is no internet (or even a reliable cell connection)? Specifically how can I have the user type a username/password to re-authenticate and get the same groups they were in when they can't access Azure services?
It appears they isn't available as the guidance always points to that is a risky proposition to have the app handle username/passwords. I understand that stance and can appreciate the caution behind it. However, in all of the ADAL documentation that I find that says this, none of them tell me how to handle an offline authentication scenario.
I have found links such as ADAL v3: How to authenticate using UserPasswordCredential? that tell me how to bypass the ADAL login page. I may have to move to that route and handle all of the username/passwords securely within the app, but first I would like to reach out and see how others tackle this scenario. Is it really as simple as avoiding best practices and just handle the username/password within the app?
If anyone has some guidance, ADAL (or other oauth providers) documentation, or other articles/advice I can follow up on to help achieve offline authentication I would greatly appreciate it!
Additional Information:
My scenario that I'm trying to cover is what happens when I have 1 device, 1 app, and many different users? These users will be in different groups that will determine how data fields get populated (filter data in combo boxes) and what previously submitted forms they can query for. All users would need to login when online to cache their information (say on Day 0) before they can ever use the app. On Day 1 user 1 uses the app and doesn't log out. I would expect the app to have a timeout timer to log that user out after 2 hours of no activity. On Day 2, user 2 just grabs the device off the shelf and takes it out into the field. He has no internet and needs to log in to determine who they are and what group they are in. I would expect since he has logged in once and verified his credentials already that we can enable this sort of scenario.
What I'm looking for is guidance if ADAL as a library can handle this or is it truly up to me the app developer to handle this sort of scenario. As I see it currently I need to store all user credentials, but at the same time it seems like everyone advises against that. I feel like I'm in a situation where I need to create a custom login screen and store the user data, SECURELY of course, even though its not recommended. It seems like all articles on how to use ADAL are written from a consumer app standpoint (or a BYOD) and don't take into account how a mobile app would be written for the enterprise.
That depends on your app design, if the first time(app online) , user login and app store all groups ,user information .After that user doesn't need to use token to get related information again(send request to server to acquire groups/user info). If app is offline , user doesn't need to re-authenticate(app controls the user session) , just get group/user information from cache . When using resource owner flow , you still need to send authenticate request to Azure AD server which need internet.
Related
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I'm currently in the process of setting up a single instance of API Management. I have a project that is going to comprise of x4 API's that are all going to be required for OAuth2 authentication.(I have a single AD tenant).
I've been following this (rather bewildering) guide on getting API Management set up with OAuth2...
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
...it specifies that you create an Azure Active Directory App Registration for...
1) The API (single API?)
2) Client that accesses the API
My question is...I know I only potentially need 1 client App Registration, but do I need x4 App Registrations for each API, or can I just use the single one and have all 4 API's use that single one?
I've tested this and it seems to work fine, I'm just wondering if I am missing a trick here and potentially painting myself into a corner later on.
I am after some best practice here on what is the right thing to do. It is less administration to have a single App Registration that can look after x4 (or more) API's, but will that cause issues later on?
Thanks in advance
While you don't technically need 1 app registration for each webapi or each app. but it's considered best practice for security and separation of apis and access to such apis, also makes it easier to audit and monitor.
However, there is nothing technically stopping you if you just want 1 app registration to handle all 4 apis. and even the client for that matter.
For example, you will have a harder time controlling access per API, eg if you want user A to be able to access api A but not B. then it's much more difficult. also, security wise, all the other apis would be able to access eachothers endpoints if you were to only have 1 app registration.
Manageability also comes into play. if for example you wanted some specific thing for one of the apps in the app registration, scopes/roles/etc. combining them would make it more difficult to do so.
Bottom line, create one for each web api under 90-95% of situations, it's best practice, and can potentially save you headaches later on.
Hope that gives you a bit of insight
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I am a beginner web designer and I am struggling to find relevant information online as to how I should go about managing my API keys for clients! I would really appreciate any tips or insights on how I should go about this!
I hold my own google account and already have my own API key (Javascript API) for my own website. Although, when creating websites for clients, is it okay to use the same API Key? Or should i create a new API Key for each client in my own account (creating new "projects")? Or should i be creating a google account for each client and then creating each client an API Key through their own account?
I also know that there are usage limits on API Keys so I want to ensure I dont exceed these if using one API for multiple sites. How can I monitor this?
Looking for any advice on the best and most efficient way to go about this. I do not know too much on how API Keys work!
Much appreciated :)
I will be using Google API as an example. Yes, you should always Create a new project for each client there are a multitude of reasons why you should do this and you already mentioned some of this
API query usage limit.
Separated client billing & usage breakdown for each project.
Security and revocation of compromised APIs.
Restricted security profiles, domain whitelisting, IP address, device usage etc..
Access management and role management.
Traffic and analytical reasons.
Creating credentials
Depending on your organisation needs and project scale, for us, we Create credentials (API key/ OAuth ID/ Service Account Key) for every platform the key will be used. For example, if we are developing an e-commerce website that comes with an app, we would issue 3 keys. (1 for web, 1 for Android apk, 1 for iOS app). This allows us to fine tune the access permissions and let us track usage.
What works for you?
If you are a freelancer or work in a small enterprise, the least you should do is separate every client by projects. There is no need to create a new Google account for each project. (You can always transfer ownership of projects to another account if your client requests at a later time)
The above screenshot is how we categorize items in our account, for each project we are contracted for (could be the same client) we will create a separate project entry.
I am trying to write an app that, upon receiving the credentials of an Azure user, will be able to show him various pieces of information using the Azure billing apis.
However, the following git sample that shows how to use one of those apis, lists a series of steps that should be done in the Azure cloud platform in order for things to work, and these steps need to be done by the user himself. Specifically, step 1 talks about registering an app and configuring it so that it has access and permissions to use the apis.
Only after those steps, will I be able to access the billing apis and retrieve his information.
Seeing as how I don't want the user to have to do anything after he gives me his username and password, is there an API or some other automated way with which I can register my app to view his account?
https://github.com/Azure-Samples/billing-dotnet-usage-api
Ideally, I would want some sort of imaginary code that maybe looks like:
someObj obj = someAPI.loginToAzureWithCredentials("123456", "someUserName")
obj.registerApplication();
Obviously the "code" is very lacking in details, but it's just for emphasizing what I'm searching for.