Azure Mobile Apps can authenticate against identity providers such as Facebook, Google, Twitter, and Microsoft. After logging in, the mobile client is returned a MobileServiceUser object. That object contains no profile information from the identity provider such as a Twitter screen name, Facebook name, etc.
How can I get that information? I'm specifically interested in a Twitter screen name, aka handle.
I'm aware of a blog post called Getting user information on Azure Mobile Services. However, it covers the JavaScript backend, not the .NET backend which I use. Also, a simple solution only involving the mobile client and not the backend would be preferable.
If anyone from the Azure team reads this, I'd love to see MobileServiceUser include profile info just like Auth0 does.
You can do a HTTP GET of the /.auth/me endpoint submitting the MobileServiceUser.mobileServicesAuthenticationToken as a header named X-ZUMO-AUTH.
This will return a JSON blob that you can decode for the user information.
And I do work for Azure - understand the request. Please post on the Azure Mobile Apps UserVoice: https://feedback.azure.com/forums/216254-mobile-apps
Related
How can I programmatically retrieve information about an OAuth client given its appId (xxxx.apps.googleusercontent.com). I am interested in retrieving Google API scopes the app is requesting (e.g.: https://www.googleapis.com/auth/userinfo.email) along with marketplace ratings and user coun t (if applicable).
Screenshot
I believe you can only access those stats if you own the app/add-on. Assuming that you're working on a GSute add-on, if you deploy the app via GSuite Marketplace you'll have to explicitly specify the scopes your app requires and you can check those scopes from your Google Console. I believe that there is also a dashboard available to the app developer (probable from Google Console) with analytic data related to performance.
Newbie question here on Authentication. I am used to incorporating authentication into my app backend server, like Spring Security Authentication for example. I don't really understand how the authentication providers work.
My concern is that somehow each provider can only authenticate its own accounts, ie google can only authenticate for gmail accounts, and Azure Active directory can only authenticate some kind of Microsoft registered account? I am disinclined to oauth because as a user I am always paranoid about signing in for some game or app from an unknown provider becacuse I never am sure whether I just gave my gmail or facebook account password to a rando.
I am fine giving people the option to use Oath, but less comfortable if that's the only option. I would like people to be able to give me whatever email address they want, and a password which they create for my site only.
Also these questions: If I use an authentication provider can I get the actual email address being used to log in? Or do I only get a token?
If I am going to build my own authentication service so I can accept any email domain as user name, what is the easiest to implement in Xamarin forms, and can somebody point me to a tutorial or something?
Advice appreciated thanks.
Yes, you're right, each identity provider provides the ability to authenticate their own users; Google OAuth supports Google accounts, Azure Active Directory supports Microsoft work & school accounts, Microsoft Account supports Microsoft personal accounts, and so on.
You have quite a few options on how to add support for these identity providers in your app, in addition to what we typically call 'local accounts', or accounts created specifically for the given application. I'll list out a few approaches:
You can write all the code yourself to integrate with each identity provider individually, and build-your-own local account solution as well.
You can use an SDK/library in your Xamarin Forms which facilitates using multiple identity providers within your app. The Xamarin.Auth package has historically served this purpose for Xamarin apps. It provides auth capabilities for Facebook, Google, Microsoft, and Twitter.
You can use a dedicated cloud service which provides authentication services for your app. Some examples include Azure Mobile Apps, Firebase Auth, Gigya, and more. The exact identity providers supported and the level of support for Xamarin/Xamarin Forms will vary across each one. Azure AD B2C is another option that I know supports Xamarin Forms as well as Facebook, Google, Twitter, and local accounts (disclaimer: I work on AAD B2C). These services sometimes have free tiers & paid tiers, so you can compare & contrast each.
You could also build your own authentication service using open source code like Identity Server if you wish.
It definitely depends which route you go, but generally speaking each solution will provide you access to some user profile information upon user authentication. For Azure AD B2C, you can configure the claims that are returned to your application in the tokens your app receives. For other services, you may need to make a REST API call to get some user data like the email address.
HTH.
We are currently using Azure Access Control Services (***.accesscontrol.windows.net) to allow customers with personally-managed Microsoft Accounts (Identity Provider) to sign in to our customer self-service portals (Relying Party Applications), which are Angular apps powered by Web API services. In our Access Control Services we are currently passing through the nameidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier claim from Windows Live ID to the relying party APIs, which match that token to an identity in our applications.
We are looking to support both Enterprise and Personal Microsoft Accounts with the Azure AD v2.0 service, but do not understand how to migrate our existing users to the new system. The code examples suggest that the OWIN middleware returns the NameIdentifier claim from the user's Identity Provider, but if that Identity Provider is the same Microsoft Account (aka Windows Live ID), will that be the same NameIdentifier we are currently receiving via Access Control Services pass-through?
Any help and/or documentation that clarifies how this transition is intended to work would be appreciated.
If the nameidentifier coming out of ACS is the randomly generated value then you're kind of stuck because that value is unique to the ACS/RP/User. If it's returning the actual Live ID then it'll obviously only match if the Azure AD user has the same email address.
I don't know if any documentation out there that describes how to handle this situation. My recommendation is to just require a one-time authentication from each source within the same session and marry the two results. That would basically mean
authenticate to Azure AD
Your app: Hey you don't have any user details, do you want to associate a Live ID?
Authenticate Live ID
Associate Live ID with Azure AD
Then if they want to sign in with either accounts in the future you have a link between the two.
I'm building mobile applications using .NET. What I'm looking for is a way to manage user sessions and info using Azure Mobile Services. I've read a lot about the authentication in Azure Mobile Services, but this only authenticates a user via Facebook, Twitter, etc ... to access azure services.
I'm looking for user session management, i.e. register, login, logout. Be able to save and retrieve user info, i.e., save certain info against the user such as age for example. Also session management and caching, i.e. the user will remain logged on when the app is closed and re-opened. Also azure mobile services doesn't seem to provide a way to allow me to register users via email.
Basically, If anyone is familiar with Parse, I'm looking for having similar functionality in Azure. Can anyone help please ?
Thanks
Out of the box, Mobile Services provides easy authentication with social providers (Facebook, Twitter, etc) and Azure Active Directory. If you want to do registration via email, you'll have to create a custom auth system. This is going to be more complex than just flipping a switch and using Facebook auth, but totally doable and I can point you in the right direction. First, check out this post that will explain how you can create a registration / login system using custom API and the script backend. If you're using a .NET backend, you'll need to alter thing a bit (the samples are in JS) but it should be pretty easy to convert. The only piece that is really missing from that post is how to do email verification. To do this with Mobile Services, I would suggest the following.
Sign up for a SendGrid account (free in the Azure store)
From your script, after registering the user, generate a random alphanumeric string that is saved to their account / user record in the table.
Use the same string to create a URL which you can send to the user's email address (check out this tutorial for sending email via SendGrid and Mobile Services).
The link can either go to a different custom API or a web front end. When that endpoint is hit, it should update the user record to show that they have verified their email address.
I took a look in some docs at developers.google and some questions here in stackoverflow and I really would like to found an objective answer about use the Google OAuth Server to authenticate an application and grant access to download docs into a Google Drive account with NO BROWSER interaction.
As far as I could look, docs like "Using OAuth 2.0 for Server to Server Applications", "Using OAuth 2.0 for Devices", answers here, I couldn't found an article saying "Is possible to authorize an application to get files from a common Google Drive account in Devices with no browser...".
Anyone have tried and had success in this jorney?
The Devices flow is meant for applications that run on devices where no browser is present (fancy example could be a wristwatch that shows new G+ notifications) and requires the user to do manual steps on a device that has a browser. Also this is for getting access to data on the user's account.
UPDATE:
As you say you have an embedded application running without a browser available and want to access data on behalf of a user, this is definitely the way to go. This however still needs the user to login (once) on another device with a browser. After you got an access token using this flow, you can then access the Google Drive API either manually or by using some library.
So you want to access data on Google Drive that belongs to a special account and only your application can access it without a browser involved?
A Service Account (the Server-to-Server flow) would be exactly what you need. These however are only for usage on a web server, as otherwise your private keyfile would have to be deployed to a client, where it could easily be extracted.
One thing you could do is use your own web server that fetches data from your Google account using a Service Account and have a client application that only connects to your own web server. This has of course also its downsides, especially when it comes to locking down your web server so no third party clients could access it.
It can be done, but a browser does need to be used. I've successfully gotten OAuth 2.0 working on an IBM i (AS/400, iSeries, System i, whatever the name is today) which doesn't have a browser. I've so far implemented the Calendar and Google Cloud Print APIs.
During the OAuth 2.0 negotiation you will be returned a URL and a code. You need to display the URL for the user to go to, then the code to enter to grant authority for that specific API/scope. I have an example in our documentation here:
http://docs.bvstools.com/home/greentools-for-google-apps/docs/g4g-base-commands/g4gregsvc
But, the issue now is that the drive API is not yet available to devices. But, Google has said that soon it should be.