How to Add GitHub Login to Your Web App with a WAF

Question

"Sign in with GitHub" is one of the first things developers reach for when an internal tool needs authentication. The usual route is a real engineering task: register a GitHub OAuth app, add an OAuth client library to your codebase, store the ClientID and ClientSecret, implement the callback handler, and manage sessions yourself.

There's a shorter path. If you front your web app with a self-hosted WAF that runs as a reverse proxy, you can let the WAF handle the entire GitHub OAuth flow — before a single request reaches your application code. SafeLine does exactly this. Here's the full walkthrough, straight from the docs.

Why do GitHub login at the WAF layer?

A WAF already sits in front of your app, so every request passes through it. That makes it a natural place to gate access. Letting the WAF handle GitHub authentication means:

• No OAuth code in your app. You don't add a client library, a callback route, or token storage.
• One place to manage identity. Add or remove GitHub login across several apps from one console.
• It works for anything. An internal dashboard, a legacy tool, or a static site can all get GitHub login the same way.

Step 1: Create the GitHub OAuth app

First you need a GitHub OAuth application to act as the identity source. This is done on GitHub's side, not SafeLine's.

From the GitHub documentation flow:

1. Go to GitHub and click your profile picture, then open Settings.
2. In the left sidebar, click Developer Settings.
3. Click OAuth Apps, then New OAuth App.
4. Fill in the application form:
   • Application name — what users see on the authentication page.
   • Homepage URL — your application's URL, for example https://a.com.
   • Authorization callback URL — your homepage URL with /.safeline/auth/api/callback/github appended. For the example above: https://a.com/.safeline/auth/api/callback/github.

Once created, GitHub gives you the two values you'll need next: a ClientID and a ClientSecret.

The callback URL is the one place people get stuck. It's not arbitrary — it's always your Homepage URL plus the fixed path /.safeline/auth/api/callback/github.

Step 2: Configure SafeLine

Now move to the SafeLine console. Go to Auth → Settings → Login Configuration, find Third-Party Login, and select GitHub.

Fill in the configuration form:

Field	What it's for
ClientID	Your GitHub application ID
ClientSecret	Your GitHub application secret
Title Name	The name shown on the blocking page — defaults to "Sign In - GitHub"
Use Proxy to Access	Check this if your requests need to go through a proxy
Auto Merge Account	Automatically match incoming GitHub logins to existing accounts by email

Click Submit to save the binding.

Step 3: Enable GitHub on the application

Configuring the GitHub source isn't enough — you also have to switch it on for the specific app:

1. Open the Applications page and select the application you want to protect.
2. In that application's AUTH page, open the Login Methods settings.
3. Enable the GitHub option.
4. Save.

That's it. The app is now gated behind GitHub authentication.

What happens when a user tries to log in

Once the AUTH feature is enabled and GitHub is selected as the login method, the flow looks like this:

• When someone visits the app, they're prompted to authenticate.
• New users authenticate, then need to be reviewed and approved by a SafeLine administrator in the console before they can get in.
• Approved users are authorized for the app and don't need another review — subsequent logins just work after authentication.
• Unapproved users are blocked when they try to access the app.

That approval step is a useful default: it stops an open GitHub login from becoming a backdoor for anyone with a GitHub account.

Managing users after login

On the AUTH → User Management page you can:

• See whether users have linked their GitHub accounts.
• Review new users for approval.
• Manage access permissions per user.
• Manually merge user accounts.

The "merge" option is handy when someone has been logging in one way and you want to fold their history into another account.

Optional: combine it with SSO

If you want users to authenticate just once and then reach several applications, GitHub login can feed into SSO:

1. Go to AUTH → Settings → SSO.
2. Enable the unified authentication feature.
3. Add applications to unified authentication.

After that, a user authenticates once — including through GitHub — and can access every application that's joined SSO.

FAQ

Do I have to write any application code for GitHub login?

Not for the login itself. The WAF handles the OAuth redirect and gatekeeping. Your app only needs custom code if it has to know who logged in — for that you'd use the auth callback flow.

Why does a new GitHub user need admin approval?

It's the default safety behavior: first-time users trigger a review so an admin can confirm who gets access. After approval, the same user logs in without further review.

Can I use GitHub login on more than one app?

Yes. You configure the GitHub source once, then enable it on each application individually from that app's AUTH → Login Methods settings.

What if my traffic goes through a proxy?

Check the Use Proxy to Access option in the GitHub login configuration. That tells SafeLine to route its GitHub calls through a proxy.

Does GitHub login work together with other login methods?

Yes. SafeLine supports several login methods (account/password, OIDC, LDAP, and GitHub), and you can enable more than one for an application.

---

Have you wired up "Sign in with GitHub" the hard way before — and would you move that identity layer out of your code and into the WAF?

---

Ready to protect your sites without paying for a cloud WAF?

• ⭐ SafeLine WAF on GitHub — give it a star if you find it useful
• 🔗 Official Docs — installation guide, configuration, and API reference
• 🧪 Live Demo — see the dashboard in action (no login required)