Get authenticated user information in Azure Api App - facebook

Context
I have a Azure Api App set as "Public (authenticated)" and have enabled Facebook identity. My Api App is protected and I am able authenticated with FB. In the Api App, I want to get the authenticated user information such as login provider, token and email to save in a database.
Problem
I can't find any documentation on how to obtain this info. I followed this article and tried
var runtime = Runtime.FromAppSettings(Request);
var user = runtime.CurrentUser;
TokenResult token = user.GetRawTokenAsync("facebook").Result;
var name = (string)token.Claims["name"];
var email = (string)token.Claims["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"];
I've made the changes to the apiapp.json file to allow facebook authentication "authentication": [{"type": "facebook"}] but it times out at GetRawTokenAsync when remote debugging the Api App.
Looking at other blogs/articles/posts, following is another way by referencing additional assemblies "Microsoft.WindowsAzure.Mobile"
var user = (MobileAppUser)this.User;
var facebookCredentials = user.GetIdentityAsync<FacebookCredentials>().Result;
But this also doesn't work as this.user is of type WindowsPrincipal user when remote debugging my Api App. And apparently "Microsoft.Azure.AppService.ApiApps.Service" is the only reference an Azure Api App needs.
Am I missing something? Seems like a basic scenario to get the authenticated user in a Api App web service.

Finally got it to work. When calling GetRawTokenAsync method we must await. Using Result or Wait from the Task object doesn’t work and times out. This is still unclear to me why, perhaps a framework bug?

Related

How to list Azure VMs using the REST API with Oauth2?

The Problem
MS Azure provides an extensive REST API. However, there is a significant amount of complexity when trying to get that API to work. From outdated and incomplete documentation to simple examples not working, performing what should be an easy task is instead nightmarish.
The Task
What are the exact, precise, detailed steps necessary to list the available VMs for someone who has logged in using Oauth2? For instance, this can be done using the azure-cli.
azure vm list
What are the steps to accomplish the same thing using REST and Oauth2?
The Requirements
The answer must not use Visual Studio, PowerShell, C#, an SDK, or any other such tool to accomplish this task. Only the portal is allowed for setup, and only Oauth2 is allowed for authorization, and only the REST API is allowed for actual information retrieval.
The answer must not simply link to external sources, although external references are encouraged for completeness.
The answer may assume the user has an Azure account. It must include information about creating the Oauth2 client, credentials, and any step necessary to get the appropriate token.
The answer must be detailed.
The answer must provide examples. Images, too are strongly encouraged.
The answer should include information about possible errors, their meanings, and what too look for to fix them.
First, we can find this rest API in azure resource portal. It is the same with Azure CLI command azure vm list.
I have tested it on my local with http request. here is my tested screenshot:
Request URL: https://management.azure.com/subscriptions/<subscription ID>/providers/Microsoft.Compute/virtualMachines?api-version=2016-03-30
Header:Authorization: bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI.....
So It is very import if we get the access token. The following demonstrate us how to get the access token.
Get Token(POST):
Request URL: https://login.microsoftonline.com/<tenant id>/oauth2/token
Body: grant_type=client_credentials&client_id=<client id>&resource=https%3A%2F%2Fmanagement.core.windows.net%2F&client_secret=<client secret>
Here is my screenshot in fildder:
We need to get client id and client secret in azure ad application. For how to regist an application in Azure AD. Please have a look at this article: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal.
Please note:
1) we need to add "Windows Azure Service Management API" in portal "Required permissions" like the following screenshot:
2) We need assign "Contributor" for this service principal. click subscription-> Access Control-> click Add -> click "Select a Role" -> click Contributor->click Add User-> Find the application you created above-> click OK.
Overview
Making requests against the Azure Rest API is a bit more complicated than perhaps you would think at first glance. In particular, there are a number of esoteric and not-so-helpful error messages you may run into while getting the nobs tweaked just right.
Introduction and Terms
Setting up The Application
Getting the access_token
Making the API request
Common errors thus far
Introduction and Terms
One of the pieces of this process that can make it so confusing and difficult is the terminology. Until you understand that, knowing how to deal with errors is very difficult. We'll go over some of the more common ones here.
Subscription - This is basically what you'd expect. It refers to the Microsoft Azure Services subscription. It basically acts as the top-level umbrella for the organization.
Tenant - This is like a sub-organization, maybe a department or group. There can be multiple tenants under a single subscription.
User - As expected, a user is a single individual. Users are scoped to tenants.
Application - The Application is the software program trying to use the API. It must be registered and configured to do so.
Service Principal - This is essentially The Application. It is the entity making API Service requests.
Setting Up the Application
Although you might not guess it, this is probably the most complicated part of the process. Let's start by creating The Application in the portal.
Create The Application
Follow this click path: Azure Active Directory -> App Registrations -> New
There should be a form for application creation, with the following fields:
Name
This is simple the name of The Application. When authenticating, it will be shown to users. For the purposes of this "tutorial", we'll call it API Tutorial. This can be edited after creation.
Application Type
The type of The Application. For our purposes, we should choose "Web app/API". This cannot be edited after creation.
Sign-on URL
The is the redirect that will be used if we go the "authorization_code" route for sign on. This can be useful as the response will include an "id_token". We'll get into that a bit later. For now, let's make this http://123AzureApiTutorial.com/code. This can be edited after creation.
Once the Application has been created, you should see a property, Application ID. This is the client_id used in the OAuth2 flow. Take a note of its value.
Create the Client Secret
The OAuth2 flow requires a client secret value for authentication.
To generate it, follow this click path: Azure Active Directory -> App Registrations -> API Tutorial -> All Settings -> Keys
Enter the key description: API Tutorial Key, and the Duration: In 1 year.
Click Save. This will generate the Key Value. You must copy the value here and save it somewhere. You will not have another opportunity to do so.
This value is the client_secret in the OAuth2 flow.
Add the correct permissions
To get to the permissions, follow this click path: Azure Active Directory -> App Registrations -> API Tutorial -> All Settings -> Required Permissions -> Add
Here you will see the list of possible APIs. The one we care about for Azure is Windows Azure Service Management API. There is currently only one permission: Access Azure Service Management as organization users (preview). Select it, click Select, and then Done.
Getting the access_token
The access_token is what allows us to make requests against the API. There are two primary ways to do this. I suggest reading about both before trying to implement them.
Authorization Code
The authorization code is a two-step process. First we obtain the authorization code, and then we use that to get the access_token. A benefit of this route is that we get back an id_token as well, with a variety of useful claims like the user's name, email address, etc.
The request format is as follows: (GET) https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<client-id>&scope=api&redirect_uri=<redirect-uri>&response_type=code&prompt=consent. Let's go over the parameters here really quick.
Tenant ID
This can be obtained be using the click path Azure Active Directory -> Properties and copy the Directory ID. This is, in fact the Tenant ID value. It just has a different name to help with the overall confusion.
Client ID
This is the Application ID we retrieved previously.
Scope
This is the scope of the code. We just want to use the API.
Redirect URI
This is the sign-on URL you specified when creating API Tutorial. After the user logs in, they will be redirected to this URL with a "code" parameter in the query string.
Response Type
This is what we want the response to be. We want an authorization code, so we just use the value code.
Prompt
This specifies whether or not to prompt the user to consent to the permissions. If we did not have this, and changed permissions, the request would just unexpectedly fail. Very frustrating. But it can be removed once permission has been granted as long as you don't change the permissions. If the application is accessing an API that requires admin permission, this value should be admin_consent.
Alright, so once we shoot off this request we will be redirected to the login page. We login, accept the permissions, and then we should be redirected to here: http://123AzureApiTutorial.com/code?code=SOME_REALLY_LONG_STRING_OF_CHARACTERS. That string of characters is the code.
Getting the Access Token
Next, we take the code and use it to get the access_token. To do so, we need to make another request.
(POST) https://login.microsoftonline.com/<tenant-id>/oauth2/token
In addition to the url, we need to add parameters. These should be consistent with the content type application/x-www-form-urlencoded. This means they are submitted as form parameters. They are as follows:
client_id
This is again the client id (Application ID) we already have.
client_secret
This is the Application Key we generated earlier. I hope you saved it! If not, go back to that step and generate another one.
code
This is the value of the code we just received: SOME_REALLY_LONG_STRING_OF_CHARACTERS.
`grant_type
Because we're going the authorization code route, this value should be authorization_code
redirect_uri
This is the redirect uri we specified for the API Tutorial. The value from our example should be http://123AzureApiTutorial.com/code.
resource
This is very important. It is the resource API we want to access. For the Azure API, this value is https://management.azure.com.
Our response will be a json object with a variety of fields. Of these, the one we care about is access_token. Yay!
Client Credentials
This methodology skips getting the code (and thus needing the redirect_uri) at the expense of not getting an id_token.
The request is the same as in the Getting the Access Token section, with a few small differences.
We do not need to specify redirect_uri.
The value of grant_type should change to client_credentials.
Alright, we have an access_token! Now we're cooking!
Making the API request
With all the prep work thus far, this is the easiest part of the process.
The API URL we are requesting against is:
https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Compute/virtualMachines?api-version=2016-03-30
Add the following header to the request:
Authorization: Bearer <access-token>. Yes, the access_token value must be prefaced with the word "Bearer" in the header value.
"But wait!" You exclaim. "How do I get the subscription id?"
Excellent question! To find it through the portal, click Subscriptions -> -> Overview and copy the Subscription Id value.
Use that value, and run the request. You should see all the vms listed!
Common errors thus far
InvalidAuthenticationToken
When making the API request, you get an error response that says something like this: InvalidAuthenticationToken: The access token is invalid. This means you haven't added the API permissions to the API Tutorial. Go back to the Add the correct permissions step and double-check you have the right permissions. Also, when requesting the token make sure you use the prompt=consent, otherwise the you will not be prompted with the new permissions and the token will fail.
InvalidAuthenticationTokenTenant
Make sure that the tenant-id used when requesting the token belongs to the subscriber used when making the API call.

Get access token via Log in with google in unity

I would like to be able to login with my google account in my unity game.
I've tried using Play Game Services, which imo would be the best solution, and I can log in and get name and ID and stuff, but I can't get the access token used, so I can verify who the user is on my server.
I have a server with a lot of player-data, that I can't put in Game Services, so I need to verify it's the correct user, and the ID is not safe enough.
How can I log in with google and get an access token in unity?
cheers
You can use this code to get token :
PlayGamesPlatform.Instance.Authenticate(success =>
{
if (success)
{
Debug.Log("Token :");
Debug.LogFormat("{0}", PlayGamesPlatform.Instance.GetAccessToken());
Debug.Log("End Of Token");
}
});
But you have to add a client id to your Google play services unity plugin.
Have you tried writing a custom Android plugin for your game?
You could get anything in your Unity game that you would be able to on a native Android app, and then pass that data to reference against your server.
They have pretty straightforward documentation for it:
http://docs.unity3d.com/Manual/PluginsForAndroid.html
I hope that helps!
Edit: Elaborated statement.
The PlayGamesPlatform.Instance.GetToken() will give you a string token, but can take a while to download, even several seconds. If the app setup is correct, it should populate after a while. Keep polling it whether it's null or empty, and it should eventually yield a valid token. The token is only good for 1 hour.
In order to access Google APIs on a backend web server on behalf of the current player, you need to get an authentication code from the client application and pass this to your web server application. This code can then be exchanged for an access token to make calls to the various APIs. For more details on this flow see: https://developers.google.com/identity/sign-in/web/server-side-flow
To get the Auth code: 1. Configure the web client Id of the web application linked to your game in the Play Game Console. 2. Call PlayGamesPlatform.GetServerAuthCode() to get the code. 3. Pass this code to your server application.
I am able to get the AuthCode and this code is given to the server and they generate the access token and authenticate my account.

Architecture for User-Registration (here: With using Facebook)

Im writing a user registration mechanism by hand so I dont want to use existing plugins or something.
Im wondering what the best way would be. I planning to do the following abstract steps:
Writing an component which is in charge to output a button which calls the facebook-api --> login in via facebook (Im getting token and user name/id)
In my route im using that Data to call the REST-Server-Backend of my app. I will pass the token as well as the username/id to the Server. (POST api.myapp.com/users)
The Server recieves the request and will validate via Facebook-API
the user data and token on its own --> if valid: Add new user to
database.
If the user wants to login now (after registration) he will do again
step no.1 and than will ask the server if the user is existing. But
how: Since ember suggest that the REST-Server is somekind of a
CRUD-Server and using the store is for working for model data only, there
is no possiblity to do a "logic"-call to the server like "ask
him if user with id is existing". Should I call "GET ../users/" and than check in my route if the sum of the returned records are smaller than 1?
So is that a common pattern?
Sounds like a fairly simple OAuth workflow but obviously refer to the facebook docs. As far as point 4 is concerned, I would suggest that yes, on login you make a request for the login route on your server (which should abstract the facebook OAuth call), and if the user is authenticated, then send down the user resource, otherwise redirect them to the login and send down some sort of 401 HTTP error.
As all your API calls should be authenticated too your user won't be able to access any protected API resources.
I would also suggest you look into an ember plugin like ember-simple-auth which also supports OAuth.
You can find more information about OAuth2 workflows here.

Setting Current User using Parse and Facebook

I just started using Parse and am very excited to get my app up and running, but am having an issue getting the current user in my server code.
I am using Parse.FacebookUtils.logIn to register and log in users for my Parse application.
After a user logs in, calling Parse.User.current() produces the correct result on the client side, but returns null on the server side.
Do I need to explicitly set the current user in my cloud code?
Thank you!
Calls to Cloud Code have the current user in request.user, you don't user Parse.User.current() server-side since they aren't logged in server-side.
var currentUser = request.user;
That's the code you use in the cloud.

OAuth 2.0 in background while creating events on GCAL from Salesforce using Google Calendar API v3 (REST API)

My Situation:
I'm trying to populate a shared Google Calendar when an event is created on the Salesforce interface. Im currently using the latest Google Calendar v3 (RESTful) API for the same https://developers.google.com/google-apps/calendar/ with APEX my development language.
I'm using a trigger that catches all the value from the fields (trigger.new) and passing those values to a class that does the JSON serialization, authentication and API call.
Till now, I was able to get all the data from the object and pass is to the class and get it serialized. But I need to do the OAuth 2.0 call before I can make a Google Calendar API call. https://developers.google.com/google-apps/calendar/
I have setup my application on the Google API Console and obtained the Client ID, Client Secret etc.
The usual way OAuth 2.0 works is that an authentication page pops-up waiting for the user to grant access to the API so that it can access the calendars linked to the users account.
My question:
Is there any way I can get the OAuth done in the background using a static/private key which is either obtained by granting access just once but not every time or just programmatically using the key value in the class to authenticate the user.
Looking forward to getting useful suggestions/inputs/help from everyone.
If the user --once-- have made the authorization you got the access_code and the refresh_code.
I found it helpful to store both codes with the application (here Firefox and password manager). With the next start of the application (Firefox/extension) I use the refresh_code to request a new access_code. That is used during the session for any further calendar call.