I'm writing an in-house app and we're using some of the Google API's in Express/node.
Since I'm only going to use one google account (an email I made just for this purpose), what's the best authentication configuration to use?
It's a service account.
From the Google Developer Console create a service account for your app, the use the API key generated in your app.
Related
I am having an unusual hard time finding an example of how to develop a multi-user Xamarin.Forms app. Imagine you wanted to develop an app for UWP, iOS and Android that users can log into and then "do stuff".
It does not matter what - for example taking notes for later access.
Since I am using Microsoft Azure, I would love to have an example which makes use of Azure Active Directory B2C for authentication (including the usage of identity providers such as Microsoft, Facebook, Google, etc.) and Azure Mobile App Service / Azure SQL, etc.
While there are samples available that show how to use ADB2C I didn't find anything related to how you would implement a multi-user app (e.g. best strategies for the database schema, access management and how this works best with an own Restful API backend and how to include it in your client code, i.e. Model, Controller,...)
Does anyone of you happen to know an end-to-end sample for this type of Scenario?
Best regards,
Christian.
To setup authentication for B2C, I would recommend MSAL. Here are some samples:
https://github.com/Azure-Samples/active-directory-b2c-xamarin-native
There are also samples available for the WebApi.
This is a simple Xamarin Forms app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access an ASP.NET Web API with the resulting token.
If you want to know how to setup your database to actually store user data, I would recommend using the claims provided in the token to identify the user. The best way identify the user reliably would be to use the objectId claim. It stays the same even if the user changes their email address.
The claims can also be used to show user information in your app, e.g. display name or email. You need to add the scope profile to your authentication request to get this data.
I have a need to move an older style Azure Mobile Service to a new Azure Subscription. In the new subscription, you are no longer allowed to create an older style Mobile Service and are required to create one of the newer Azure Mobile Apps. I have already moved the database (fixed changes with the column names, etc.), and have the easy tables and easy API migrated and working based on a NodeJS back-end. The only thing that is left is to add authentication to the mobile app to secure the back-end. The way the app was originally developed is that the mobile client SDK passed a secret key along with the endpoint URL in the MobileServiceClient constructor and a custom username/password form passed the user entered credentials to a mobile API method that would validate the user contained in the database. The updated client SDK now only accepts the endpoint URL.
Everything that I see online for the new Mobile Apps wants to authenticate with AAD, Facebook, Twitter, Microsoft Account, or Google. We do not want to change our authentication. How can I easily add the same type of authentication to the new Mobile App without having to use Facebook, Google, Twitter, etc?
The easiest method is to implement some sort of custom authentication, just like you did in your Azure Mobile Service. The same principals apply - you submit the username / password to the backend. The backend generates a JWT and then the client submits that information for the rest of the session.
I covered Custom Auth in node early on in my blog series: https://shellmonger.com/2016/04/08/30-days-of-zumo-v2-azure-mobile-apps-day-5-custom-authentication/ - that one uses Auth0 to handle the actual user database, but the same principals apply.
I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.
I'd like to add an Office365/Graph Calendar integration to an existing Node.js app (hosted on AWS). I've already done a similar integration with Google's Calendar, and it was trivial to get set up. I'm not having nearly as much luck with the Microsoft version of things.
I've found at least 4 different ways to register an app (get a clientId and clientSecret), and I seem to get different errors for each of them, but can't get any to work properly.
I think a large part of my problem is that I've never had to work in the MS ecosystem before, so I don't have a lot of the baseline knowledge that the documentation assumes.
I'm not looking to host anything with Microsoft - do I even need an Azure account?
I'd like to allow any user with an Office365 account to connect it to my app - do I need to learn about Active Directory to do this? Does this part of it require Azure?
I've found instructions for using both https://login.microsoftonline.com/common/oauth2 and https://login.microsoftonline.com/common/oauth2/v2.0 for this, do I need to worry about which version I use depending on how I registered my app?
Microsoft Graph leverage Azure AD to authenticate and authorize users. The doc refers as:
To get your app authorized, you must get the user authenticated first. You do this by redirecting the user to the Azure Active Directory (Azure AD) authorization endpoint, along with your app information, to sign in to their Office 365 account. Once the user is signed in, and consents to the permissions requested by your app (if the user has not done so already), your app will receive an authorization code required to acquire an OAuth access token.
So you need to register an Azure account for configure the Azure AD service. Refer https://graph.microsoft.io/en-us/docs/authorization/app_authorization for more info.
Meanwhile, to implement Microsoft Graph in node.js application, you can refer the following code sample for your information.
Microsoft Graph service app sample using Node.js
An Office 365 API sample app using Node, Express and Ejs
Office 365 Node.js Connect sample using Microsoft Graph
Matt, you can do this without an Azure account if you use the oauth2/v2.0 auth endpoint. When you do that, you can register on apps.dev.microsoft.com using a Microsoft account.
See this tutorial for doing it with the Outlook REST API, which is similar to the Graph (in fact, for Calendar operations the calls and entities are identical).
I want to store user information to a db after a user successfully logged in via a social provider (google, facebook, etc.) without calling an extra api on the client side.
In azure mobile services this is done by creating a class that inherity from e.g. GoogleLoginProvider and then by overwriting the CreateCredentials method.
See this post: Save information immediately after Google login in Azure Mobile Services (.NET Back-end)
But how can I archive the same behaviour in Azure App Services?
Thanks
Unfortunately this is not possible with App Service authentication. The authentication happens outside of your application and there aren't currently any direct hooks into the authentication pipeline. This also means you will not be able to inject custom claims into the ClaimsIdentity.
We are aware of some of these scenarios and want to try and address them, but don't have any timelines to share at this point. I believe the separate API call into the backend will be required in order for you to implement your registration. As far as implementing role-based access control, you will likely need to store the additional user metadata elsewhere.