Obtaining an Azure Maps Access Token using a Azure Function - azure

I'm trying to obtain a Azure Maps Token using a Azure Function based on the following documentation.
How to secure a single-page web application with non-interactive sign-in
Does anyone know how to create a Azure Maps Client using .NET similar to this?
AzureMapsManagement client library for JavaScript

They just released a .NET client library yesterday. You can find it here: https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/maps
For example, if you wanted to use the search API, you would authenticate
in a similar manner to the JavaScript client library:
AzureKeyCredential credential = new AzureKeyCredential("<My Subscription Key>");
MapsSearchClient client = new MapsSearchClient(credential);
Here is some documentation on this client library: https://learn.microsoft.com/en-us/azure/azure-maps/how-to-dev-guide-csharp-sdk
For token base authentication you can use the Azure.Core.TokenCredential class. A good article on the different ways to do this can be found here: https://www.rahulpnath.com/blog/defaultazurecredential-from-azure-sdk/ (not putting code in stackoverflow as there are a lot of different ways depending on your scenario).

Related

How can i safely pass access token generated from Google OAuth to a NodeJS REST API?

I am creating two application :
1. Chrome extension for gmail.
2. It's IOS version
Now, since both the applications have same behavior and uses same google apis extensively, i decided to create a single project in google cloud platform for both. Now, when creating credentials, what will be my application type? I see both 'IOS' and 'Chrome App' under application type. Should i generate two Client IDs for chrome app and ios app?
To use single Client ID, i also tried creating a Node REST API (created a new project and set application type to 'web application' in google cloud platform) that will be used by both of my application to make request to google apis? But the authorization process includes, setting a callback url to get the authorization code and later use this code to get the access token. I guess this is not feasible for a REST API. Where should i keep the authorization part? In the application itself and later send the access token to my rest api? Is it possible?
I am very much confused about how should i start. Please could anyone suggest a better way to do this?
I generated two client ids, one for ios and for the web. Isolating both applications is a good way to start. Both the apps generate their own token id, pass the id to Node Rest API and later the use that token to make a request to Google APIs.

How to safely call Azure Function with function level authorization in Xamarin mobile app?

I'm making an iOS/Android app using Xamarin (not Xamarin.Forms, just regular Xamarin). I'm using the shared library set up rather than PCL. I want my app to call an Azure function but I'm unsure of the safest/best way to handle this. I have it set to "Function" for the "Authorization level". The test URL includes the "?code=..." portion in it. I was under the impression that if I put that in my C# code with the "code" value exposed that it was considered a bad idea from a security perspective.
I'm lost as to the safest/best way to deal with this. I've read that setting it in app.config is also a bad idea. I found some references for a web app that suggest using the connection strings that are available in the azure portal, but since this isn't a web app, I'm unsure of how I'd actually retrieve those values in my code (or if that's even possible).
So how would you suggest I handle setting the value for "code" so that I can call my function and avoid a security problem?
UPDATE: Providing more info as per request:
I'm using MSAL to authenticate my users with a B2C active directory. I already have that part working and have received a token authenticating the user.
I also just now enabled authentication in my functions.
I was under the impression that to call my function from my mobile client I had to make a new HttpRequestMessage. I'm unsure of then what I'd place in it to pass my token along.
Just to make sure I understand, your concern is about embedding secrets (the ?code=XXX value) in your iOS/Android app, correct? If so, yes, this is generally considered bad security practice. It's best to assume that anyone who can download your app will have the ability to discover these secrets and use them any way they want.
The recommended way to authenticate with a backend service, such as Azure Functions, from a mobile device is to use interactive authentication - i.e. some kind of OAuth flow. You can build it yourself, or you can use the built-in functionality of Azure Functions and Azure App Service to help you (Azure Functions is built on top of App Service). Here is a resource which might be useful:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://contos.io/working-with-identity-in-an-azure-function-1a981e10b900#.vcjit3ntw
The API Key (code) is indeed not meant to be used by clients you distribute externally, so it shouldn't be used by your mobile app.
The most straight forward option here would be to use the built in App Service Authentication features with Azure Functions and implement an authentication flow in your app, which would allow you to securely authenticate the user.
Sharing more information about your scenario may help identify alternatives.

Azure Mobile App Authentication using Xamarin

I read these two articles 1.here and 2.here to find out what is best way to perform authentication against an Azure Mobile App when the API on the server is using Claims based custom authorization and the Xamarin client calling it is using the MobileServiceClient framework. I am unable to finalize which of the two examples in those links is the better way to go.
In the first link there doesn't seem to be any dependency on platform specific code like it has in the second link, which means I don't need to write any code in the Driod or IOS or Windows projects and can get away with doing everything in a class library itself.(Am I right here?)
Also, the first link seems to not require any provider like the second link does because I am invoking a direct service call to a Url. The second link on the other hand only seems to support Facebook, Twitter, MicrosoftAccount, Google and WindowsAzureActiveDirectory. The mandatory MobileServiceAuthenticationProvider parameter doesn't seem to provide for Custom Authentication against a sql server based User table. I am not sure about this part and cant find documentation that says otherwise.
If LoginAsync doesn't provide for Custom Authentication then its clear that I will need to follow the InvokeApiAsync route. If it does provide it then the question is: should I write platform specific(Droid/IOS/windows) code in each target project like in the second link or should I handle all the service calls in a class library as can be done in the example shown in the first link? In other words should I go with LoginAsync or InvokeApiAsync? Which of the two is the recommended way?
The first article shows off custom authentication, as you intimated. The second article shows off App Service Authentication, which has a known list. If you need to do a custom username/password, then go with the former. If you need to go with social auth or enterprise auth, then go with the latter.
My general recommendation is don't require the user to create yet another username unless you have to - which means social authentication for consumer apps and enterprise authentication via AAD for enterprise apps.
My other recommendation is to always use the client SDK for doing the authentication part. This allows you to follow the very latest practices from the provider (facebook, twitter, etc.) in respect to security, refresh tokens and other authentication requirements. Once you have the provider token, it's easy to swap it for an Azure Mobile token by using LoginAsync() with a token. See the Azure Documentation for information on this.
In all cases, you are going to need platform specific code - that means using the DependencyService (as in the second example) to execute your login code. I generally create a singleton class that wraps the MobileServiceClient in the PCL. Then create an ILoginProvider interface which has LoginAsync/LogoutAsync code in it to handle the platform dependency code. My singleton class then calls the DependencyService to get the code. You can find an example in my GitHub Repository that covers iOS, Android and UWP.

Microsoft Account Authentication in API App on Azure

What I'm hoping to accomplish is a connection to Visual Studio Team Services through the Microsoft Account authentication provider. I've been following the documentation here (https://github.com/Azure/azure-content/blob/master/articles/app-service-api/app-service-api-dotnet-connect-to-saas.md) and have a couple problems with the implementation.
They use the Microsoft.Azure.AppService.ApiApps.Service package to get to the token from the api gateway
// Retrieve the token from the gateway
var runtime = Runtime.FromAppSettings(Request);
var dropboxTokenResult = await runtime.CurrentUser.GetRawTokenAsync("dropbox");
But when I publish my webapp I get a 500 error when trying to create the Runtime object, the remote Debugger literally just dies on the line below and I don't even see any logs in the api's streaming logs interface to give more info on the error.
var runtime = Runtime.FromAppSettings(Request);
Any idea on how to get to the token?
Documenation for implementing microsoftaccount authentication with a web api is kinda scarce, any links to examples or documentation that was helpful to you guys out there?
Also, is the apiapp.json file really even necessary? They create one in the example but authentication setup Via the Azure blades seems to work ok and leaving the apiapp.json file out of the api doesn't seem to matter either way. In the end I'd like my web api to maintain authentication via microsoft account no matter where it's moved to, so I figured there would be settings somewhere I would need to specify but can't really put that piece together either.
It looks like you're using the old model for building API apps (which involves a gateway) which has been deprecated. I believe its still supported, but the official way to build API apps has since changed, and you might find it a bit simpler to work with. More information can be found here: https://azure.microsoft.com/en-us/documentation/articles/app-service-api-whats-changed/
Documentation for leveraging Microsoft Account authentication is here: https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-microsoft-authentication/
Once you're all set up, there are a few different ways you can obtain the token. You can find it as an inbound HTTP header (x-ms-token-microsoftaccount-access-token) or you can use the App Service Server SDK to obtain it: something alongs the lines of:
var creds = await this.User.GetAppServiceIdentityAsync<MicrosoftAccountCredentials>(this.Request);
string accessToken = creds.AccessToken;

WIF and REST is it a good fit?

We have bunch of web applications which are secured using WIF and custom database authentication, currently we are in the process of building a RESTful public API. My question is whether we can use the existing WIF implementation to authenticate these new RESTFul service requesuts?
Thanks!
You can take a look at those two blog posts relating how to use WIF to secure an OData endpoint (which is REST on steroids):
http://blogs.msdn.com/b/astoriateam/archive/2011/01/20/oauth-2-0-and-odata-protecting-an-odata-service-using-oauth-2-0.aspx
http://blogs.msdn.com/b/astoriateam/archive/2011/01/21/connecting-to-an-oauth-2-0-protected-odata-service.aspx
I'll be in the process of integrating WIF with classic-REST and OData endpoints shortly, if you have any feedbacks, I'm interested.
Vincent-Philippe
REST services typically use different token formats from those supported by WIF out of the box (e.g. SWT vs SAML). You can extend WIF so it understands the appropriate token format. There are many examples that show how to do that.
See here for an example: http://zamd.net/2011/02/08/using-simple-web-token-swt-with-wif/

Resources