What do you need to do to a JsonServiceClient in order to call a remote service that is secured by oAuth providers (i.e. Facebook, GooleOpenId etc) + AuthenticateAttribute?
My client has already authenticated against facebook?
How do you configure the JsonServiceClient object here and with what?
Any examples of this? It seems to be a very common scenario of a Xamarin phone app calling a secure and remote web service, that's all we are trying to do here.
Related
Currently doing some research to setup an (azure) api gateway with oauth (jwt token) security.
an external partner/app sends a request to an api endpoint published on the gateway including a valid JWT-token in the header that gets validated by the gateway against AzureAD for example. When validated the request is routed to the backend service. No problems here.
My question is, what is best practice for the external app to obtain that JWT-token (to use for the api call) ?
Obviously, It could send a request to AzureAD with a clientid+secret to obtain a valid JWT token. But to do so it has to call my internal AzureAD directly ? Is this the way to do it ?
or should I expose a 'get-jwt-token' api on my api gateway and route that request to AD ? How should I secure that API ? with basic auth ?
or am I missing something, and is there a much better best/proven practice ?
HOSTING BEST PRACTICE
A reverse proxy or API gateway is placed in front of both APIs and the Authorization Server (AS). This ensures that an attacker who somehow gains access to the back end entry point cannot access data sources.
OAUTH REQUESTS TO GET TOKENS
OAuth requests are typically proxied straight through the reverse proxy / API gateway to the AS with no extra logic. All credentials, auditing of login attempts etc remain in the AS.
MANAGED SERVICES
If using Azure AD as a cloud managed AS, this is a special case: the system is already hardened for internet clients, so most companies don't add their own proxying - though it is possible to do so.
FURTHER INFO
The first of these covers the infra setup and the second gives you an idea of extensibility options once a reverse proxy / gateway is in place.
IAM Primer
API Gateway Guides
I created an Azure Mobile App Service which is currently accessible 'Anonymously'
Anonymous access is enabled on the App Service app. Users will not be prompted for login.
To make it secure I can enable App Service Authentication which will ask users to log in
But this is not what I want - The data in this app is only accessed by Application without the need of each and every user to login to my app before using it.
So you might say, in this case, Anonymous access is fine but I want to restrict it with something at least like an API Key so I will have access to the API which my app can use to access the data to prevent random requests as anyone can just go and use Postman and start getting data without any authentication.
So in short, I don't want individual user authentication, but at least an API Key to ensure only requests made from my app are authenticated and nothing else.
I am using the following in my mobile app to create a connection and also doing Offline sync etc
MobileServiceClient client = new MobileServiceClient(applicationURL);
Any idea how do I do that?
FYI. My server side backend is in C#
Since you are using Azure Mobile Apps, for your requirement, you could leverage Custom Authentication for building your CustomAuthController to login and generate the JWT token for a specific user without user interaction. The core code snippet for logging would look like as follow:
MobileServiceClient client = new MobileServiceClient("https://{your-mobileapp-name}.azurewebsites.net/");
client.LoginAsync("custom", JObject.FromObject(new{Username="***",Password="***"}));
Note: As the above tutorial mentions as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
And you must explicitly add [Authorize] attribute for your controllers / actions which need to be authorized access. Details you could follow Authentication in the Backend.
I tried to implement custom Authentication via a authentication endpoint in an azure mobile app. I've created an Api Controller, that creates the Jwt using Azures AppServiceLoginHandler.CreateToken method. When I post to this controller with turned off Azure App Service Authentication, I get a token, but when I want to use it later, I always receive a "401 Unauthorized".
But when I turn the setting on in the Azure Portal, and send the very same request
I get:
The requested resource does not support http method 'GET'.
I'm not changing any code, and I'm certainly using a POST request - The exact same request, that works with turned off App Service Authentication.
My Code is essentially the same as here:
https://www.newventuresoftware.com/blog/custom-authentication-with-azure-mobile-apps
Could someone enlighten me here? Do I need additional configuration somewhere?
As adrian hall's book about Custom Authentication states as follows:
You must turn on Authentication / Authorization in your App Service. Set the Action to take when request is not authenticated to Allow Request (no action) and do not configure any of the supported authentication providers.
For custom authentication, you need to turn on the Authentication / Authorization in your app service for authenticating your token. Moreover, I would recommend you leverage fiddler to capture the network traces to narrow this issue. Additionally, you need to make sure that you send the custom login request with HTTPS. Details, you could follow this similar issue.
My question is [Similar to this one1, but with third party providers instead of active directory.
I have an end-user UWP app, and I want to consume my Azure API App. I am NOT Azure mobile app and it's client side SDK.
Most of documentation is of sort "copy paste this magic code" and never explains how authentication actually happens.
I was inspecting mobile app SDK because Microsoft's documentation says that it's auth. process is the same.
From what I see, the mobile App SDK opens a web-view very similar to that produced by a WebAuthenticationBroker. Then every request to the server is accompanied by a header X-ZUMO-AUTH and a token. It appears that this token is issued by the azure app service, not the original provider. It is much longer than the tokens issued by Twitter or Google.
At the same time when I point web-browser at the end-point and go through the log-in process, I see that the browser is using a Cookie: ARRAffinity=c4b66198677464de573103f7aa267c33ea38617020514011cea4506e0a55d9d0; AppServiceAuthSession=EIVymV
Questions:
The problem is Mobile app documentation is it just provides
instructions on how to use the SDK. I am unclear on how I would
obtain the token issued by the app service.
Everyone knows how to obtain access tokens for Google
and Twitter. Can they be used to access Azure API apps?
You are correct that API apps use the same built-in authentication as mobile apps. The basic flow looks like this:
Login to the app using provider credentials. This can be done using either a client-directed flow using your provider's SDK or can be done using a server-directed flow involving browser popups (i.e. the web view you mentioned). In the latter case, there is an endpoint at /.auth/login/ which is provided by App Service and manages the login flow for your app.
App Service will respond to your client app with a session token (a JWT).
You call into your APIs using the session token from #2. It is passed via the x-zumo-auth HTTP request header (it's named this way for legacy reasons).
The AppServiceAuthSession cookie you are seeing is the session cookie for when you use a browser to do authentication. ARRAffinity is an internal routing cookie used by App Service and is not related to auth.
If you're looking for more internal technical details on how the built-in App Service Authentication / Authorization works, check out my blog, starting with this post: http://cgillum.tech/2016/02/01/architecture-of-azure-app-service-authentication-authorization/
I am building an online application using AngularJS on the front-end, hosted in an MVC 5/Web API application (basically a single-page application). However I have a hard constraint: the application's data will be held in a private network. I have to build a second Web API application inside the private network that exposes the web application's functionality. Further, the user authentication needs to happen inside the private network API (so the private network API will act as the authentication provider), as this is where the user tables exist.
The app in the DMZ is basically going to act as a proxy to the web API in the private network. So every request received in an ApiController in the UI API will be calling the private network API, ideally passing the token on received in the initial request.
From an authentication perspective, this is what I need:
User navigates to the site, can see only certain pages (I want to use MVC filters in the view controllers to control access).
They will log in once with a username and password.
After login the user can navigate to application pages and as a result the pages will call into the DMZ API for data.
This DMZ's API controllers will be calling into the private network API.
Both APIs whould be able to identify and apply authorization on their controller methods, based on the user's credentials.
If I didn't have a need for the second tier of API I would just use the MVC Single User Authentication implementation, which provides support for both cookie (UI) and token (API) authentication.
Any help providing insight into how I can do a similar thing with the above scenario would be much appreciated. (I guess my requirement is a bit like Windows impersonation for the UI web app).
See below for a high level view of the static architecture:
You may want to look at Azure service bus relays, which are designed to bridged the corporate firewall and call on-premise APIs.
Your WebAPI service would authenticate against the service bus to be allowed to call your service through it. You can pass user credentials using a bearer token in the request.
I'm not sure, but you may need to change your backend service implementation to use WCF though. You can find an explanation of the use of relays in Microsoft Dynamics in this link.