I'm building a .net backend for my Azure Mobile Service.
I would like to execute code whenever someone authenticates with one of the default providers (i.e. Microsoft, Google, Facebook etc.).
Some examples of what I would like to do during authentication:
Associate their MS/Google/FB Account ID with my own user accounts
Add claims to the ServiceUser
To sum it up: is there any way to hook into the server side execution of MobileService.LoginAsync(provider) in a .net backend?
Yes, you should look at the custom authentication feature of Mobile Services, which should be flexible enough for your use case: https://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-get-started-custom-authentication/
You might also be interested in the new AAD B2C offering, which has a lot of features that might fit your scenario: https://azure.microsoft.com/en-us/documentation/services/active-directory-b2c/
Related
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'm looking to see if it's possible to use both individual user accounts authentication along side Azure AD authentication in a single application. Either Framework or Core (ASP.NET).
So far it's been all Google searching and I'm not finding anything that clearly states one can do this. Secondly, I'm not very familiar with authenticating an application aside from the basics for both individual or azure ad (well documented examples / VS template code).
Any help, links, small code example from Startup.cs is greatly appreciated.
Thanks.
It's too vast topic to put into an answer as a how-to-guide. However, I would try to give you brief overview and enough references/examples to look at. Your scenario can be better solved by using Azure AD B2C in conjunction with Azure AD. I strongly suggest you to go through the overview from those links for foundational concepts first. Azure AD B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
In your case, you need to add Azure AD as identity provider in the B2C tenant, and add required User flow (personal/social login) which will enable your user to login with either organizational (AAD) or personal/social account by signing up. This explains how to configure custom policies in B2C to add AAD as identity provider in such case. And for example, this provides you guide to enable Azure AD and Facebook login.
Now coming to code/SDK part, since you are into C# and asp.net, your one stop shop should be the new Microsoft Identity Web library. It would make your life lot easier to wire up with Microsoft Identity Platform with minimal configuration and code, and also has pretty good documentation, reference and samples to handle most common scenario. For example, this is a sample for B2C. There are many more here for your reference in case you need.
I would emphasize your starting point should be Microsoft Identity Web for asp.net core.
I have an Azure account and currently a Mobile Service setup with a SQL Database so that my Windows Store app can communicate with the database.
I have developed sites using ASP.NET WebPages authentication. And I need something similar for my Windows Store app.
I have successfully gone through the documentation and tutorials on the Windows Azure website and implemented ACS (Windows Live ID, Google, Yahoo!, and Facebook) - but the thing is - I don't want Google, Yahoo!, Facebook or even Windows Live ID or Microsoft Account) logins - I want my OWN login but it seems that they don't give you this option (correct me if I am wrong).
I need to allow users to signup from within my application (that means, providing their name, DOB, email, phone, address, etc) and shove it all in my database.
Now, after implementing Microsoft Account login with my Azure service, I found out that you can't even get the most basic information about any user who has logged in to your application - not even an email address.
I have spent hours searching online for something that could possibly help but I am running out of keywords - and have not hit a single related result yet.
Does anyone know if this is possible? How would we go about integrating login and signup with a Windows Store app that set/gets this data into/from a Windows Azure service?
Any code, samples, links, tutorials, documentation, etc would be highly appreciated.
You have gone down the road of hooking up external identity authentication, which in my opinion for an external facing web application is a better approach. Benefits are:
Your application is only responsible for Authorization not Authentication. There is a whole lot of work involved in Authentication and a large number of best practices. Best let those who know best take the burden of this. This doesn't mean you shouldn't try and understand it though.
If your site gets hacked you don't have to tell them that their username / email and password combo has been compromised and they will probably have to change there passwords on other sits.
You are also making sure that your users don't have to remember / manage yet another username / email address password combo
If you really want to do the Authentication then that is fine but you will need to do it yourself. Have a look at examples on Asp.Net Membership. This is not the only way and nor is it the best way but there are lots of examples.
Now if you decide you want to use external authentication I can give you some pointers to help with your current implementation.
First thing to note that the Id you get back from Live, Google, Facebook can only be assumed to be unique for that provider. Therefore if you want to keep a profile in your system for that identity and you want to use more than one provider you will need to implement it in such a way that you can keep the id unique in your system and help you associate it with a provider.
Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider
As you have found out not all of the Authentication providers return the same "claims". A claim is something that user claims to have, such as an email address, name, date of birth, etc. All the ones you can use by default via the ACS return Uid and some return a name and email address. What you have to do is fill in the gaps. When someone registers you will need to pull the relevant claims and then ask them to fill in the missing ones. You may also want to map the different claims in the ACS to a common name that you can use in your app as one provider might use slightly different names.
Federated Identity with Windows Azure Access Control Service
Just because you do not handle Authentication you still need to be responsible for keeping your application secure. Half of the work has been done for you so your code should be a lot lighter but you will still need to make use of roles.
Windows Azure Role Based authentication (ACS)
The really nice thing about this approach is you can implement your application the same why SO have done with there identity model. You can allow users to associate multiple identities against their profile meaning they can login how they want to.
If you choose not to use the built in providers for ACS you will need to implement your own Identity Provider using SAML, OpenId, etc...
You can look into the Windows Identity Foundation (WIF) for implementing WS-Trust or WS-Federation.
There is also ADFS which has the same set of support but uses Active Directory with WIF and Azure has its own version of AD that can be used.
There is also thinktecture identityserver which can jumpstart your venture into IdP land, but I have not used it myself yet.
If you want to go the OpenId route there is DotNetOpenAuth.
If you're looking to add custom identity to your Mobile Services app, check out Josh's post on custom auth: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx
I am trying to use Google shopping API. In order to use the API, my application should be authenticated using OAuth2.0. Looks like this method involves user interaction (where user allows the application to access the resource)
Is it possible to do OAuth authorization in non web applications with no user interaction?
This may be a good case for using a Service Account. This would mean that your application isn't running as a user but as itself. That is, as a made up account corresponding to your APIs Console project.
Various official client libraries support the Service Account flow as described in the link above, but C# is not listed among them, so you may have to write it yourself. (Though this issue claims it's supported in the google-api-dotnet-client library, I couldn't find the source for this feature after a minute or two of looking).
Can Windows Identity Foundation allow us to connect to services and read contact information?
Here is a idea of how WIF advantages:
WIF externalizes authentication,
passing it over to security token
services (STS) and reducing the
demands on individual developers
WIF
also supports trust relationships
where a service trusts anyone
authenticated by the application
accessing it.
WIF provides support
for a single sign-on (SSO) for users
by sharing STS among applications.
Developers can also, at run time,
support both by creating a trust
relationship between the application
and service or bypassing the user's
credentials from the application to
the service.
Depending on what you want to do, the answer is Yes.
Using Azure ACS federated to WIF e.g., you can connect to Facebook and get all the Facebook user attributes that you have asked for (provided that the user agrees during login to provide them). You can also connect to Google.
Or you can write your own custom STS federated to WIF that has some kind of interface on the other side that invokes a service and passes the details through e.g. using DotNetOpenAuth to handle the OpenID protocol. See StarterSTS as an example.
Watch this video as a starting point. There is a link for the source code and documentation, so you can see if the direction fulfils your needs.