3 Testing with Postman - adamhockemeyer/Azure-Functions---CosmosDB-ResourceToken-Broker GitHub Wiki
Testing with Postman as a client
For simple testing, I'm going to use Postman to demonstrate exchanging an Azure authenticated credential with the Azure Function which will create an user in Cosmos DB, create a permission for that user, and return a Cosmos DB resource token which can then be used for subsequent calls directly to Cosmos DB from the client SDK.
It should be noted that typically a client sdk such as the Microsoft.Azure.Mobile.Client would typically handle redirecting you to the appropriate login url (based on what you selected) and take care of retrieving the token from the result.
Login
To be able to login to our functions that we previously added authentication to, we can open a browser and type the following into the url:
Provider would be aad, google, facebook, microsoftaccount, or twitter.
Entering this url will either prompt you to authenticate with the selected provider, or, if you have already authenticated with the provider and a cookie is present in your browser, you will be redirected then to login/done page.
Also for reference, you can go to the following link to logout of your session:
After you login, your browser will redirect to a different url which actually has your authentication token url encoded into it. Copy this.
If you then take this url and paste it into a a url decoding service, you will get a JSON result which includes your authentication token or easyauth token.
You will want to copy authenticationToken and pass it in the header of our Postman calls so that the request is authenticated.
Get the Authentication Token
Now that you have your authentication token, you can use this to call resources that have been protected in Azure using the "Authentication\Authorization" page that we saw in the setup of our Function App.
By using the "Authentication\Authorization", we need to pass this token a certain way in order for the pipeline to detect that the request has been authenticated. Azure uses a plain header (read: not Authentication header) called key "x-zumo-auth" along with the value of the decoded token (starting with "ey") as described above.
With Postman, we can setup the header, and call /.auth/me, another special url that is setup since we have enabled the "Authentication\Authorization". This url will give additional information and claims about you as the user logged in.
We want a piece of this information in our ResourceTokenBroker function app code so that we can get the user_id of the user that is signed into the app.
Get Details with the Token
If we scroll towards the bottom of the JSON result, you will see a property of "user_id" and the value will most likely be your email address. This is what the code in the Functions App will call to get the user_id of the current user requesting access for a resource token.
Get Cosmos DB Resource Token
Finally! We can use the authentication token we received from login in to call our "CosmosDBResourceToken" function which returns us a resource token that the client app can then use to make calls to Cosmos DB directly.
The resource token is used by the client sdk to make calls to Cosmos DB based on the permissions that the resource token has for the user.
The object received back from our function include the resource token that we got from Cosmos DB, as well as some helper information such as when the resource token expires (unix epoch time) and the userid of who the token is for.
Note 1: Ensure that the resource token has the word "resource" in it and not "master". If you gave a user a "master" key, they would potentially have the ability to do any administrative (add/delete) tasks, similar to the Azure portal.
Note 2: Notice the "code" query string parameter. If you have enabled "function" authentication for your function app, you will need to get your function code from the settings in the portal. This is a code that is appended to function calls to add as an additional layer against unwanted requests. "anonymous" authentication would not require this code to be in the query string.
The same access token that we decoded above could then be used to access any protected resource in our function app. Note that this is just the "Authentication" part, which says that the user is can come in, but then you still will need to manage the "Authorization" part which allows the user to only access the information that they have permission to.