Hey, thanks for the interest in this post, but just letting you know
that it is over 3 years old, so the content in here may not be accurate.
With Azure Static Web Apps we get a user profile as part of the security platform, but that profile is pretty limited, we get an ID for the user and something contextual from the authentication provider, like an email address or a username. This means that if we want to create a more enriched user profile, we need to do it ourselves.
So, let’s take a look at how we can do that. For this demo, I’m going to use the React SWA template, the npm package @aaronpowell/react-static-web-apps-auth and @aaronpowell/static-web-apps-api-auth. We’re also only going to use GitHub as the authentication provider, but the pattern displayed here is applicable to any authentication provider (you’d just need to figure out the appropriate APIs).
Authenticating a user
First we’re going to need some way to log the user in, or at least, checking that they are logged in, so we’ll wrap the whole application in the ClientPrincipalContextProvider component:
Having this ContextProvider means that we’ll be able to use the useClientPrincipal React Hook (which the package ships with) to check if the user is logged in or not within our application, and that’ll be critical to make the right decisions throughout the app.
Let’s rewrite the App component to use the useClientPrincipal hook:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function App() {
const details = useClientPrincipal();
if (!details.loaded) {
return (
<section>
<h1>Loading...</h1>
</section>
);
}
// todo
returnnull;
}
The loaded property of the Hook state is indicating whether or not we’re received a response from the /.auth/me endpoint, which is what we use to determine if someone is authenticated to our app, if they’re authenticated, we’ll get the standard profile back, if not, we’ll get a null profile. Once this has completed we can check for a clientPrincipal:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
function App() {
const details = useClientPrincipal();
if (!details.loaded) {
return (
<section>
<h1>Loading...</h1>
</section>
);
}
if (!details.clientPrincipal) {
return <Login />;
}
// todo
returnnull;
}
This uses the component from @aaronpowell/react-static-web-apps-auth and disabled Azure AD and Twitter, which are part of the pre-configured providers.
Getting the GitHub user info
Before we can finish off the UI component, we need some way in which we can get the user’s information from GitHub. Let’s do that by adding a new API to our SWA:
The first thing this function is going to do is check that there is a logged in user, using the isAuthenticated function from the @aaronpowell/static-web-apps-api-auth package (you don’t need to do this if you configure SWA to require the call to be authenticated, but I tend to do it out of habit anyway).
Assuming they are logged in, we’ll make a call to the GitHub API to get the user’s details. It’d be a good idea to provide an authentication token to do this, so you don’t get rate limited. Aside: I’m using Buffer.from("...").toString("base64") not btoa to do the encoding, as at the time of writing the API that SWA deploys runs Node.js ~12, and btoa was added to Node.js in ~14.
How do we know the user to access? The clientPrincipal that we get back has the userDetails field set to the GitHub username, so we can use that in the API call.
And then assuming that’s successful, we’ll return the fields that are we care about back to the client.
<GitHubIdentityContextProvider>
We’re going to build a new React Context (+ Provider) so that we can finish off our App like so:
First thing, let’s create a TypeScript type for the user, obviously skip this if you’re not using TypeScript.
We’ll then create our React Context using createContext and call it GitHubIdentityContext. We’re not going to export this from the module, as we don’t want people creating their own providers using it, we want to do that for them, so we can control how it populates the profile data.
The GitHubIdentityContextProvider is a React Component, which uses the useClientPrincipal Hook and tracks the GitHub user details as local state. We’ll use an effect Hook to wait for the profile to be loaded, and if it has been, call the new API that we created earlier in this post (I called mine user-details). Unpack the response as JSON and push it into state, now we have the GitHub user info available to our client.
Lastly, we’ll create a custom Context Hook to expose this and export them from our module.
function User() {
const githubUser = useGitHubUser();
if (!githubUser) {
returnnull;
}
return (
<div>
<h1>{githubUser.name}</h1>
<h2>
Works at {githubUser.company} in {githubUser.location}
</h2>
<p>{githubUser.bio}</p>
<ul>
<li>
<ahref={githubUser.html_url}>Profile</a>
</li>
<li>
<ahref={`https://twitter.com/${githubUser.twitter_username}`}
>
Twitter
</a>
</li>
<li>
<Logout />
</li>
</ul>
</div>
);
}
With a null check to ensure it isn’t used in the wrong place (and to satisfy the TypeScript compiler that we aren’t using a null object 😜) we can dump out the profile in whatever format we want.
And there we have it, an Azure Static Web App with authentication provided by GitHub, along with a rich user profile.
This repository contains a template for creating an Azure Static Web App projects using React + TypeScript.
In the template there is Create React App site using TypeScript and an api folder with an empty Azure Functions, also using TypeScript.
To get started, click the Use this template button to create a repository from this template, and check out the GitHub docs on using templates.
Running The Application
From a terminal run npm start from both the repository root and api folder to start the two servers, the web application will be on http://localhost:3000 and the API on http://localhost:7071. Alternatively, you can use the VS Code launch of Run full stack to run both together with debuggers attached.
Static Web Apps does a good job of giving us the building blocks for creating an authenticated experience. In this post we’ve looked at how we can take those building blocks and create a rich user profile, provided by the underlying GitHub API.
Although this sample is GitHub centric, there’s no reason you can’t apply the pattern against any other authentication provider, including custom ones. You could even make an API that looks at the identityProvider property of the clientPrincipal and call Azure AD, Twitter, or any other provider in use.
I’d also suggest that you explore how you can effectively cache this data locally, either in a user store in Azure, or in the browser using localStorage or sessionStorage, but there are privacy considerations and data purging to think of, which is beyond the scope of what I wanted to cover in this post.
Hopefully this helps you create apps with richer user profiles.