Azure Functions : 401 Auth Error

Continuation...

The TL;DR; part below was my log of working out 401 auth errors; I've since solved that problem and posted the solution here.

Azure Functions and graphQL

John Peters ・ Feb 15 '21

#nextjs #react #azure

TL;DR;

Now that the apollo-server is deployed in an Azure function let's fix the 401 Auth. Errors.

Scenario: You've just deployed an Azure function containing an Apollo-Server. Everything works on Azure: deployment, graphQL playground, Test and run.

But... when attempting a HTTPPost Request from your application client side on localhost:3000/myreactapp you see 401 errors.

According to this post, there exists an optional module which intercepts all inbound HTTPRequests for the app service (your function or website).

The work it does deals with the Authentication and Authorization world. It is able to stop any unwanted intrusion.

It does this via "Claims" which is a word for "inbound information that describes things"; such as, I claim to be a specific:

• username or id
• fullname of user
• e-mail address
• group membership
• phone number
• color of eyes

For Azure Functions, user claims are in the request headers or the ClaimsPrincipal (ignore for now).

Token Store

A repository of things called 'tokens'. Tokens are associated with the users of your application. This store is automatic when we enable authentication for our function application. Tokens are used by the client side which retrieve them, ask for a refresh (they have time limits). The token store keeps an active cache.

Identity Providers
For this article we'll mention just a few...

• Microsoft Account
• FaceBook
• Google

These are three services that say "I will provide identify services for this person". This is also know as a 'Federated Sign-in'.

Two Modes of Sign-in

Each of the three identity providers above have SDK (Software Development Kits) for identity.

This allow us to use Authentication using:

• No SDK
  • Where our application allows our app-service to do the dirty work.
  • Also known as 'server-directed flow' or 'server flow'
• With SDK (Azure Functions and Rest APIs)
  • The application itself does all the dirty work. Used for browser-less application where the user interface doesn't exist.
  • Also known as 'client-directed flow' or 'client flow'

The Authentication Flow

For Functions, it looks like we need to use the SDKs like this:

Client -> get Auth Token
Client -> Post token to /.auth/login/
Client <- Appservice Token
Client -> uses X-ZUMO-AUTH

Configuration

Time to turn on our "module" that intercepts all inbound requests and ensures it's ok to continue.

Open your Function App Service, then select (for now) "Allow Anonymous requests (no action)"

Test Time
With our function application already deployed and working (we see the graphQL playground) with the right url.

With a local copy of a React application that has an HTTPPost request like this:

 let r2 = await fetch("https://apolloexample.azurewebsites.net/graphql",{
      body:JSON.stringify(`{hello}`),
      method:'POST',
    });

It should work right?

Wrong! It didn't work... But why? Our other function call worked. Yes but it's not running an Apollo-Server, it's just an HTTPTrigger to return a JSON string. This tells us that there's more to the Apollo-Server thing.

The Apollo-Server
In our Azure portal we are able to navigate to our (AS) Apollo-Server function no problems, we can even see the 'playGround', issue queries and it all works.

Keys
Go to your function app portal for the apolloexample click on the 'App Keys' icon. Notice these?

To be continuted..

JWP2021 Azure 401