I would like to secure my Azure WebApi with 3rd party providers (FB, G+... I basically just need a valid email). Was looking at Auth0 and seems like it will do the thing paired with Jwt middleware in web api project, but I was wondering if the same can be done using Azure only.
Azure Web App authentication confused me a bit - it does not seem to give anything to my Asp.Net web app. I still have to configure all the middleware in Startup.cs and the app still works fine if I completely turn authentication off.
I could do the same thing Auth0 does - issue my own Jwt tokens based on access tokens from FB or G+ - but would like to avoid that.
Could you please point me to the right direction?
You have a couple options:
App Service Authentication
Configure the authentication via middle ware
App Service Authentication
The App Service Authentication does not require any code inside your application because your App Service has a gateway that inspects request for authorization. Depending on the setting you can either secure the entire site or secure individual resources (by using the [Authorize] attribute on the endpoint in MVC/WebAPI).
With the latest release you can control authorization on a site by site basis including manually triggering the sign in by navigating the user to the <yoursiteurl>/.auth/login/<provider>. By defualt the token store is enabled so you can make a request to <yoursiteurl>/.auth/me and get back information from the provider.
Middleware Authentication
This is the default way authorization happens in the Single Page ASP.NET Template. The middleware authentication uses OAuth/OpenId to secure the resources. This option does it at the application layer instead of at the gateway. If you are using ASP.NET Identity (from the single page project template) the email from the persons log in will automatically be stored in the Users table. The tutorial in the link above gives lots of details on how to get it working.
Make sure you use the [Authorize] attribute to trigger the Authorization in either case.
Hope that helps you get started in the right direction.
Related
I am researching the feasibility of porting an existing Vue 2 app to be an Azure Static Web App (SWA). A requirement is the ability to run the Vue app locally and authenticate against our Auth0 tenant to retrieve a access/bearer token to send along with our HTTP requests.
It appears that a SWA can utilize custom authentication (Auth0), and I was able to complete that successfully by following this article. However, I'm not seeing any information around capturing the access token. There is an /.auth/me/ endpoint which has user information, but that does not contain the access token:
I also looked into the Azure Static Web App Emulator which allows for defining an identity profile when running locally, but I'm not seeing a way to specify an access token here either.
Is it possible at the moment with a SWA to obtain an access token using a custom auth provider when running locally and when published live?
Managed Authentication in Azure is really only useful for fairly simple use cases. I think you're going to want to implement your security directly inside your Vue application.
https://auth0.com/docs/quickstart/spa/vuejs/01-login
You mentioned needing an access token but didn't say where it comes from or what you're doing with it. Are you trying to call an Auth0-secured API?
https://auth0.com/docs/quickstart/spa/vuejs/02-calling-an-api
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/
Consider the following (common) scenario. I will first try to specify how I understand a (nice) Web API should look like, using OAuth. Please do correct me if I got any of the flows wrong.
My API: the center of attention, all clients use this.
My Web App: Uses the API just like any other client would.
My Mobile App: Also uses the API, the same exact way as the web app. Users should be able to authenticate without opening a browser.
3rd party Web App: Also uses the API - however, the user/resource owner must grant permission for the app to do something. They do this by redirecting to my site (or opening a popup to it), logging the user in if necessary, and prompting the user for access.
3rd party Mobile App: Same requirements as the 3rd party web app.
The Question(s)
Should the API handle authentication and authorization?
How does the API know who (the resource owner that is using the client application), is using the API?
When a user is using my official clients, they should obviously not have to grant any permissions - my clients should have all permissions. How would I distinguish between my official clients, and 3rd party clients when calling the API?
Here is what I understand, and would do so far. This is where I really need help - getting this done right.
Official Web app
- Client attempts to `GET /api/tasks/".
- API says "who are you? (HTTP 401)
- Official web app redirects to login form.
> Bob enters his credentials.
- .. now what? Get an authentication token? Cookie?
Since the web app is just a consumer of my API, how would I manage the logged-in state? Should the web app do that?
Should the web app have direct access to the users database instead of verifying credentials against the API?
I am using .NET (C#) primarily, but I'd love an approach that is applicable to, say, Node JS based API's as well.
How would you go about this? Especially the client flows are a problem for me. The reason I ask, is that I have read that you should not roll your own security solution unless absolutely necessary, so if there are any standard-ish guidelines for this, do let me know. :)
Take a look at the new web API 2 oAuth stuff.
Basically fire up a new web API project and ensure you select to change the authentication.
Then, it's a simple case of calling the register controller. This then creates a token for you which can then be sent in the header of each request for that user.
Check out the API calls using fiddler and create some mock up accounts.
It's been awhile, but I thought I would document what I ended up doing.
I use DotNetOpenAuth. I have a database with clients, and they have a Trusted field - if this is set, it lets the client use the password grant, which automatically grants all scopes that have been predefined for that client.
The 1st-party web app uses plain cookie auth - exposing the client credentials in JS would be too risky.