Entra to GitHub

Entra to GitHub: enterprise identity at the API edge

Getting from Microsoft Entra ID to a GitHub-native platform is an identity problem, not an API problem. Zekt Gate validates an Entra access token, works out which Zekt customer it belongs to, decides whether the operation is allowed, and forwards an attributable request to Zekt — so a developer portal never has to hold a GitHub identity to reach GitHub workflow orchestration.

Why there is a gap at all

Zekt authorizes through GitHub. That is the right model for its primary consumer: a workflow in GitHub Actions calls the native action, and GitHub identity establishes who is asking.

An enterprise developer portal is a different caller. Backstage, or an internal portal, authenticates people through the corporate directory — in many enterprises that is Microsoft Entra ID. It has a perfectly good identity for the person and no GitHub identity at all.

The workarounds are worse than the gap. A shared service account belongs to nobody and audits as nobody. A personal access token belongs to whoever left. Neither is an enterprise identity boundary; both are a way of not having one.

What happens to a request, in four steps

1. Prove the token is real

The signature is checked against the issuing tenant’s published keys. The issuer must be the expected Entra issuer, the audience must be the Zekt Gate API, and the token must be inside its lifetime. Key rotation in your directory is ordinary behaviour and needs nothing from you.

2. Work out whose call it is

The tenant claim is mapped to an enrolled Zekt customer. The calling user or service principal is identified, and so is the client application — which must be one this customer allows. The customer context comes from the validated token and never from the request.

3. Decide whether it is allowed

A valid token is not permission to do everything. Delegated scopes and application roles are evaluated, the requested operation is checked against customer policy, and anything uncertain fails closed.

4. Hand Zekt a request it can trust

The call is metered for usage attribution, provenance and correlation context are attached, the existing Zekt Directory, Registry or Orchestrator API is called, and the result is returned unchanged.

What this is and is not

Zekt Gate does

Validate Microsoft Entra ID tokens at the API boundary
Translate a validated enterprise identity into a Zekt request context
Authorize the operation against customer policy
Meter the call and preserve correlation provenance

Zekt Gate does not

Issue an identity of its own — it has no login, and sign-in happens at Zekt
Manage your Entra environment, or ask for permissions to do so
Replace GitHub identity for callers who already have one
Hold domain logic — Directory, Registry, orchestration and billing stay in Zekt

Tenant isolation, concretely

Customer context is derived from the validated token, so a token issued by one tenant cannot reach another customer’s data by changing a URL segment or a field in the body. There is no request parameter that selects the customer, because there is nothing for such a parameter to do.

That is a property of the code rather than of the infrastructure, which is why it is tested rather than configured.