I am looking at adding custom authentication to my existing Xamarin.Forms app through Azure Mobile Services. Currently, my app authenticates itself against an existing WebAPI but the authentication isn't secure and I don't really want to start trying to create my own secure authentication process for production. I thought that Azure Mobile Services would be a good way of being able to keep the custom authentication side of my app (authentication against a current identity provider isn't an option) however I already have all the storage etc set up in an existing SQL database by sending it to the WebAPI first and then saving details.
I guess my question is: Is it possible to set up Azure Mobile Services with my current WebAPI acting as a kind of middleman? The basic workflow would include my app sending the log in details to the WebAPI, the WebAPI passing these on to Azure Mobile Services for authentication and then returning the response including token to the app after being stored on the WebAPI side.
The reason I thought that Azure Mobile Services would be a good choice was because it also provides support for push notifications as well as the custom authentication side of things.
Thanks.
Take a look at the following for custom authentication: https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/
Short version - yes, it is possible. You create a custom WebAPI that mints a ZUMO token within your Azure Mobile Apps SDK Within that minting process, you can check the users credentials (either a token, remote API or whatever) any way you want.
I am not sure if that is possible. You are trying authenticate through two different application. It might be possible to write the mobile service client login code in your web API app to use authentication from Mobile Service app and get the token back. But then you still have to manage the user sessions between your Xamarin app and web api app, cross origin stuff and etc,
Since mobile service app really is a web api wrapped with some extra functionality, have you considered moving your web api app to mobile service? That might be easier in my opinion.
Yes, this is possible.
In our app the user is able to register and to login with twitter and Facebook but with own email + pw, too.
In wams we sync the social account and "our" account (stored in the db).
Have a look at ClaimsIdentity and Microsoft.WindowsAzure.Mobile.Service.Security IServiceTokenHandler to implement custom authentication and returning a custom token.
Related
I'm working on a Windows Desktop application that needs to authenticate to a Web API that uses JWT.
We are using the authentication based on if the end-user of the desktop client is successfully logged into their computers with a smart card. So if they are logged into their computers, we pass a specific piece of that data to our Web API to verify that value is in the database of the Web API, and then that particular data will use that to determine the roles. JWT works excellent and has no issues. We are accomplishing JWT via this article: https://auth0.com/blog/add-auth-to-native-desktop-csharp-apps-with-jwt/
Is there another way to make sure they are coming from our desktop applications and not hitting our API via another application in the network? Or do we not need to worry about that since they have been pre-authenticated into the computer itself.
I am currently building an api along side our external app developers. I have read that the Authorization Flow with PKCE is definitely what we need for this set up however I am looking for some more detailed advice.
Our existing api uses the implicit flow and the app sends credentials + secret etc to the /Token endpoint in the api this then looks up the passed in data and compares with our users table. If that passes an Access Token is returned to the app.
With this new flow I have the following questions.....
Do I have to use Okta Portal/Dashboard and set up the api there?
Do all app users have to be stored in Okta dashboard? We usually manage our own users table where we add users from a custom tool. However I am presuming when using Okta our custom tool would need to call Okta api endpoint and register the user from there and then get and store the users Okta ID in our own table. **Does anyone have an example of how I do this from a C# Wpf application?
Do I then need to request the Redirect URL's from the App developer and set them up as a Native App in Okta dashboard. Presuming I need to give them some set values to hold their end to allow them to call Okta at authorization.
OpenID????? do I need this if so how and where does this get implemented?
I have read through so many tutorials but just havent quite found the exact fit yet.
Many thanks
You will need to access Okta admin console to register a client application. Once done, you can use Okta OIDC API's: https://developer.okta.com/docs/reference/api/oidc/.
You can use Okta SDK's to simplify the development process. Ex: https://github.com/okta/okta-oidc-ios
If Okta is going to be the authorization server, users and their credentials will need to exist in Okta
When you create a native App in Okta admin console, you will need to provide the redirect URI's that will be whitelisted
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. When you create a native application in Okta, will be a OIDC application.
I am new to .NET core and while I have .NET experience, I have never built authentication, in the past I've always worked on project not started by me. I am just trying to learn and find good resources and I would greatly appreciate if anyone knows tutorial or if it can explain how to solve this.
When using external logins, I followed those instructions here. This all works well if I create simple web api project and run, I get a web page where I can login, authenticate, works perfect. But this is not my end goal, I am building Web APIs not a Web Application. In my case let's say I have iOS and Android apps and my external login is done on the app itself, how would I pass token to Web APIs? I want to use [Authorize] method in Web APIs to make sure that no un-authorized access is made agains APIs and in addition to that I would like to use roles.
I am assuming token information is passed in header. But what is the header name for token? Can external authentication be used with roles or that is only possible if I store username/password? Can you point me to some good tutorial or anywhere I can learn more because all google search returns back to same like I have mentioned above and it is not very descriptive.
In general , your web api will work like a identity provider , it will issue and validate the JWT tokens :
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
You can also implement authorization with the help of your external login provider .If you have SDK or own code in your client app to help do authentication , for authorization part , you can also register your web api in the same identity provider . For example , you are using the google authentication external login in your client app , you will should register your client app and web api on google's application registration page , then you could use OpenID Connect hybrid Flow to authentication user and get access token for accessing web api . Each identity provider provides how to implement authentication/authorization with lots of documents.
You can have an endpoint that allows anonymous access and takes the token and verifies it. Then it can send back a JWT that contains claims/roles that you want to enforce on the specific user. Every time the client accesses a secure endpoint, it can send your JWT in the header which gets verified before the specific method in your API controller is called. You can look into OAuth flows if you want to integrate social logins.
For example, Google has this documentation for OAuth-
https://developers.google.com/identity/sign-in/web/backend-auth
I have an Azure-based .NET Core Web API application that I want to communicate with an Azure-based MVC5 application. The MVC5 application requires its clients to have a credential in our Azure AD instance. We connect to this app with our SSO Azure AD credentials.
The .NET Core app does not authenticate against Azure; there's no credential pass-through possible for its consumers. BUT... it's hosted in the same Azure instance, so it seems like I should be able to send an authenticated request from the web api to the MVC app with relative ease.
The documentation on this is quite confusing though. There's talk about x.509 certs (this really doesn't seem necessary), OAuth 2.0 grants and flows (I may not be able to get around that, I don't know)... but is there some simple, relatively "brainless" way to have the one service talk securely with the other without building some kind of complicated scaffolding and/or configuration? I'm kinda hoping there's a way to just instantiate a HttpClient or WebRequest, call some method to get the proper Authorization header (or maybe cookie?), and send my request on its merry way... but if it exists, it remains elusive to me.
Any elucidation on this would be helpful, thanks.
This sort of depends. First, to be clear, you are trying to call an action in the MVC app from the API app? This seems a little odd (more often, a MVC front-end might need to call the api). Regardless, it should still be the same.
Question: Do you want you api app to always call the MVC app as "itself"? So, your api app would have an identity that is authorized to call an action on your MVC app? If so, this is exactly what the OAuth Client Credentials flow is for:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service
With this flow, you create an Azure AD application registration that represents your API app. Then, at runtime, your API app uses its client id and client secret to acquire a token it can use to call the MVC app (typically passed as a bearer token in the Authorization header). Part of what you can do with the app registration is give it delegated access to your MVC app, but you can also manage which "clients" you want to allow access in your MVC app.
Hopefully this makes sense.
I'm a bit confused regarding the authentication/authorization setting on the settings blade for an Web/Api App in Azure.
If I enable Azure AD authentication via the portal.
Is there any way to get hold of user information in the actual service then?
I know there is the Bearer security header, but can I extract any useful information from that?
Or is the authentication/authorization setting acting only as a proxy before the call to the service. that is, it requires valid AD credentials, but the service never have to deal with any of the details around it?
What would be the main differences between using that setting vs. creating an Web/Api App that uses Asp.NET authentication via code. e.g. its possible to set that up using the standard ASp.NET templates.
In those templates you get an OWIN app that uses an Azure AD authentication provider.
If I use the latter, is there any benefit from the authentication/authorization setting? or can I simply ignore that if the App itself has an authentication provider?
Using the authentication in the portal allows you to get some very rudimentary information about the logged-on user via the header "X-MS-CLIENT-PRINCIPAL-NAME", and you also have access to whatever claims are passed in. There's a good example here: Websites-Authentication-Authorization