I have a web app configured in my Azure AD.
On a machine, i have installed a connector and configured an application proxy with that connector.
I am now trying to connect from an Android mobile application to the web app through the application proxy.
If I use a WebView inside my app, I can load the User access URL, enter my credentials and I receive a cookie for use by following connections.
I need to be able to use other HTTP clients that do not have the possibility to show UI.
I was wondering if it was possible to somehow request access and refresh tokens, and add those to future requests. or if possible convert them to a cookie in some manner and add that in a header.
Your client app can simply use MSAL (or ADAL, or another OpenID Connect client library) to sign the user in and an access token for the App Proxy app. Then you can include that token in the Authorization header in requests to the endpoint from App Proxy. App Proxy will recognize it, validate it, and (if everything checks out) proxy the call down to the App Proxy connector, where the rest of the process happens as normal.
Here are the relevant docs: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-native-client-application
Related
I have been trying to configure access to an on-premise Web API from a native application using this walkthrough: How to enable native client applications to interact with proxy applications
According to the walkthrough,
"To support native client applications, Application Proxy accepts Azure AD-issued tokens that are sent in the header."
However, regardless of the tokens that I send in the request header, the proxy always responds with HTTP 302 and redirects me to the sign in page.
Has anyone been able to pass Azure app proxy pre-authentication using a token?
I have a on-premise API that use OAuth, so I use the "Authorization:Bearer ..." header when calling it from on-prem. Now I want to call this API from external using Azure Application Proxy with authentication. I know how to acquire a Bearer Token to authenticate against the Application Proxy.
The problem is that in the same HTTP Call to the on-prem API from external, I need to have 2 different "Authorization:Bearer ..." headers, one for the Application Proxy and one for the on-prem API.
I cannot just have 2 Authorization headers, right? So how do I call my on-prem API from external?
Edit : I've never found the real solution so I built an "On-Premise Proxy" that swap Authorization:Bearer after the Azure App Proxy. Here's how it works :
The outside app inserts 2 headers with the call to Azure App Proxy (AAP). First is Authorization:Bearer with the token required by AAP. The second is a dummy header "AuthorizationOnPrem" with the token that is required by the app behind the Azure Proxy (on-prem).
The Azure Proxy redirect the call to my custom "On-Premise Proxy".
This On-Prem Proxy copy the token from AuthorizationOnPrem to Authorization.
Then the On-Prem Proxy call the real on-prem app with the same data that it got called but with the right token.
I know it's quite patched but it worked for me with the on-prem app I needed. And it was surprisingly easy to do. Might not scale well though.
I am trying to authenticate to a server from my React-Native app using Azure AD.
Now, I don't understand what is a redirect URI and I don't understand where should I put my server's URL in Azure and what URL should I call from my React-Native app.
Documentation for it is quite confusing.
I don't understand what is a redirect URI
For React-Native app, the redirect_url is optional. Refer to this document for more details.
An url that ADLoginView will be redirect when login success, this property is optional.
I don't understand where should I put my server's URL in Azure and
what URL should I call from my React-Native app.
You needn't put your server's url in Azure.But you need to add authentication to your server. Then you can call your server api as normal, but with the Authorization header. This sample will help you to understand better though it is using aspnetcore.
You need to create register two applications in Azure portal. Client app and server app. You will get the access token via your native app and then use it to access your server app.
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.
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/