I need to Register an App in the Azure Portal in order to retrieve a Token for my Windows Desktop application.
Do I select Web App / API or Native?
APPLICATION DETAILS
The main application is a Windows Desktop Executable. It does NOT run on a handheld device (e.g. SmartPhone) NOR is a web browser involved.
We've created a type library using EWS Managed API in order to create appointments directly in Exchange (we use Exchange On Line). Now we'd like to use OAuth APIs for Authentication.
Use Native. It corresponds to OAuth2 public client concept - an application that cannot use/protect secrets. Use WebApp/API for Confidential Clients, e.g. web apps (except SPA), batch services running in protected environments, etc.
Related
I'm trying to create a web api in Azure that allows a user to access it.
I don't care whether the user calls the api via postman, curl or a .net console app, as long as the user can authenticate against the AzureAD protecting the resource, he should be in.
However, all documentation I have seen so far require me to register a client with AzureAD.
So, I've got an example working, but I had to register the console app in AzureAD.
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
How can I actually do that? I care about users, not client apps.
Or is this something AzureAD B2C does?
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
You only need to register one app(web app) to protect the web API. And if you want the web api consumed by different organization, you need to enable the Multi-tenanted feature on the Azure portal.
After that, if the other developers want to consumer the web API, they also need to register the one app on their tenant and grant you web API app to their app. After that then can acquire the access token for the web API and request the web API with the access token.
More detail about the scenario about calling web API, you can refer the code sample below:
active-directory-dotnet-webapp-webapi-openidconnect
And if the sencario is multi-tenant, you also can refer the document below about detailed info:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
I am building an iOS application with swift and this application has a web client that's using Microsoft Azure services. I want to add sign in and login functionality to the application using Microsoft Azure. I am not using any cloud applications or services. I will just have simple forms for signing up and logging in. I want to be able to save user credentials to authenticate and authorize them when they are using the application. I tried reading over their documentation and It seems to me that I need to use Azure Active Directory but I am not clear on that.
I am fairly new to Microsoft Azure, Can anyone clarify to me if I can use it and provide resources of how to do that.. ?
The simplest way to implement that is to use Azure Mobile Apps - it is the backend-as-a-service. You are able to connect your backend with the authentication providers of a choice - Facebook, Azure Active Directory, custom provider, etc. Then, when user will try to authenticate, all of the authentication code will be handled by a cloud platform - user will enter his credentials, these will be sent to the auth provider and if they are valid it will send the auth token that you will be able to use in your app to get his information, etc.
Here is the tutorial for Mobile Apps for iOS.
Or, you may use Azure Active Directory directly as a provider (it will serve as a catalogue of your users). Using that tutorial or the samples from the official library. But i would highly recommend to look at Mobile Apps as it is the fast and simple way to implement what you need.
I have developed an API using ASP.NET Web API 2 to be consumed by applications in my domain. I want to secure the access to the API endpoints. I've decided to use the OAuth token based token authentication for mobile app clients and web app clients.
However there are some non-interactive windows service clients that need to consume the API. I do not want to store login credentials to get a token in the service config, however a Windows authentication suits this type of client.
Is it possible to use a hybrid - windows and token-based authentication in ASP.NET WebApi? How?
I think the Windows authentication service from Identityserver might be a good solution for your problem
You can find more information on : WindowsAuthentication repo
I have decided to break up the API into two. One for normal OAuth based access and the other with specific resources using Windows authentication to be consumed by non-interactive windows service clients.
is the SAML protocol (Sing Sign ON) used soley for web apps and web services, or is it also used for standard applications?
REVISED:
I am looking for some windows (Standard Applications (not web based)) protocols for Single Sign On
If you are looking at Windows specifically, why not use Kerberos and Integrated Windows Authentication? It's built into Active Directory and Domain Controllers. It doesn't really work once you start crossing into the Internet and different security domains but it works well behind your firewall in a corporate environment.
However, SAML can be used for desktop applications. I've run into applications before that would retrieve the Kerberos ticket from the Desktop, make a WSTrust/RST call to an STS to validate the Kerb token and get back a SAML token in the RSTR that would be embedded into a Web Services call that the desktop application needed to make.
SAML allows secure web domains to exchange user authentication and authorization data and by definition would require an internet connection to do so. So no you would not want to use it for a desktop application.
Revised
here are the links for active directory implementation with Delphi.
http://www.agnisoft.com/white_papers/active_directory.asp
http://adsi.mvps.org/adsi/Delphi/index.html
I'm working on an application which allows data entry and display from both a Windows Phone application and an MVC 3 web interface. Data access for the phone client is via authenticated WCF services hosted in the MVC 3 application. Users will be tracking information which is unique to them, so the service will only show me data which I have entered.
What is the simplest way to handle identity in this scenario? I'd thought of using Windows Live ID, since the phone application has access to a Windows Live Anonymous ID property. However, from what I can tell there's no way to get allow for a web-based Windows Live sign-in which gives me the same Windows Live Anonymous ID - Windows Live Messenger Connect login gives me a site-specific unique ID, which would be different from the phone client's Anonymous ID.
Alternatively, I could use Facebook authentication on both client and phone with Facebook SDK. My concern there is in securing the service calls. I'm thinking that the first time a device connects with the service with a Facebook ID, the server issues it a key, and both the Facebook ID and the server issued key are required for service access.
Thoughts on the above? Is there a simpler solution that I'm missing?
Dear Jon,
I have no experience on WP development but I have made a a little search for WCF Auth. for couple of days recently and found out that the apiKey auth is nearly the best way to me. Rob Jacobs has explained how it works on this article;
http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx
An alternative to an API Key is to use claims based identity and security tokens. You could use the Windows Azure Access Control Service as a trusted issuer of security tokens, with the value add that it comes pre-configured to use LiveID, Facebook, Google, any OpenID and any WS-Federation identity provider. Both the web site and the web service would trust ACS.
ACS will give you SAML tokens for the web site (allowing your users to login to it with LiveID, Google or FB).
ACS can also issue Simple Web Tokens (SWT), which are especially neat for REST services (assuming the phone client uses that).
You can't use the LiveID associated with the phone in your app, but you can still use LiveID (or any other identity provider). This is an example of how to do it. It uses the common approach of embedding a web browser in the phone app and use to for all security token negotiation.
Using ACS gives you a lot of flexibility without all the complextity. Making a web site "claims aware" and trust ACS is very straight forward. More samples here: http://claimsid.codeplex.com
If you need to link the Phone to a user on the MVC site you could do what Netflix and Amazon do for Roku and other devices and have some sort of an activation process. To make it easier you could use a QR Code or some other type of barcode generated by the MVC site, have the user take a picture of it, and process the image using the Silverlight ZXing Barcode Scanning Library. Probably a bit convoluted, but it works for all the set top boxes.