OAuth

Introduction

OAuth is an authorization standard that lets applications obtain tokens without exposing user credentials. VeilNet can use OAuth-issued JWTs to automatically create secure connections between applications.

Prerequisites

• Your identity provider supports OAuth.
• Your application obtains JWTs from your identity provider.
• Your identity provider publishes signing keys via a JWKS URL.

Configure OAuth Identity Provider

VeilNet can work with any JWT-based identity (user or machine) as long as the token can be verified via JWKS. At a high level:

• Obtain a JWT from your identity provider (via any flow your app uses).
• Provide VeilNet with the token and the metadata it needs to verify it:
  • JWT: the token itself
  • JWKS URL: where VeilNet can fetch signing keys
  • Issuer: the iss claim in the token
  • Audience (optional): the aud claim (use this if you want to restrict tokens to a specific API/service)

If your provider issues opaque access tokens by default, you’ll need to configure it to issue JWT access tokens for your API.

Example: Client Credentials (machine-to-machine)

Most providers support the standard token request:

curl -X POST "$TOKEN_URL" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" \
  -d "audience=$AUDIENCE" \
  -d "scope=$SCOPE"

Then take the returned access_token (JWT) and pass it to VeilNet along with the JWKS URL, issuer, and (optionally) audience for validation.

Use JWT to create secure connections

During registration, you can pass the JWT, JWKS URL, issuer, and audience to let VeilNet verify identity and automatically enforce access between applications.

package main

import "github.com/veil-net/conflux/anchor"

func main() {

  // Configure the 
  idp := &anchor.IDPConfig{
        JWT: "your-jwt",
        JWKS_url: "your-jwks-url",
        Audience: "your-audience",
        Issuer: "your-issuer",
    }

    subprocess, _, err := anchor.StartConflux(token, tag, ip, idp, nil)
    if err != nil {
        log.Fatal(err)
    }
    defer subprocess.Stop()

  // Your application code...
}

Note: VeilNet Guardian validates the JWT via the JWKS URL, but does not store the JWT. JWT scopes can be used to derive identity-based permissions for Packet-Level Authentication. No additional configuration is required once your JWT can be verified.

Warning:Taint can override identity-based access control. For example, if only some workloads have JWTs, you can apply a shared taint to allow communication between specific client and server applications.

Provider guides

Here are some common identity providers and how to configure them to support your applications Authentication.

These guides are examples, not an exhaustive list. VeilNet is not tied to any specific vendor: any OAuth/OIDC provider is supported as long as it issues JWTs that can be verified via JWKS (with the correct issuer, and optionally audience). If your provider can publish signing keys and mint verifiable JWTs, it can work with VeilNet.

Auth0

• Docs: Client Credentials Flow, JSON Web Key Sets (JWKS)
• Create: an M2M application (client) and an API (resource).
• Set: the API Identifier (this becomes the audience).
• Mint token: use Client Credentials against Auth0’s token endpoint.

Typical values:

• Token URL: https://<YOUR_DOMAIN>/oauth/token
• Issuer: https://<YOUR_DOMAIN>/
• JWKS URL: https://<YOUR_DOMAIN>/.well-known/jwks.json

Okta

Okta can mint JWT access tokens via an Authorization Server (often a “default” server in dev environments).

• Docs: Implement OAuth for Okta with a service app, Authorization Server Keys
• Create: an application/client as needed for your flow.
• Ensure: you are using an Authorization Server that issues JWT access tokens.
• Configure: audience and scopes for your API.

Typical values (vary by org and authorization server):

• Issuer: https://<YOUR_OKTA_DOMAIN>/oauth2/<AUTH_SERVER_ID>
• JWKS URL: https://<YOUR_OKTA_DOMAIN>/oauth2/<AUTH_SERVER_ID>/.well-known/jwks.json
• Token URL: https://<YOUR_OKTA_DOMAIN>/oauth2/<AUTH_SERVER_ID>/v1/token

Azure Entra ID

Azure commonly uses App Registrations. JWTs can be minted for both user flows and client-credential flows, depending on your setup.

• Docs: OAuth 2.0 client credentials flow (v2.0), OpenID Connect (OIDC) on Microsoft identity platform
• Create: an App Registration
• Configure: the audience/resource for the API you want tokens for
• Mint token: using the flow appropriate for your app (user sign-in or client credentials)

Typical values:

• Issuer: https://login.microsoftonline.com/<TENANT_ID>/v2.0
• JWKS URL: https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys
• Token URL: https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token

Keycloak

• Docs: Securing applications and services with OpenID Connect, Securing Applications and Services Guide
• Create: a realm and client
• Ensure: the realm publishes JWKS and your tokens are JWTs (standard OIDC setup)
• Mint token: via your chosen flow (user login or service account/client credentials)

Typical values:

• Issuer: https://<KEYCLOAK_HOST>/realms/<REALM>
• JWKS URL: https://<KEYCLOAK_HOST>/realms/<REALM>/protocol/openid-connect/certs
• Token URL: https://<KEYCLOAK_HOST>/realms/<REALM>/protocol/openid-connect/token

GitHub Actions OIDC

GitHub Actions can mint an OIDC JWT for CI workloads (no client secret). This isn’t OAuth client credentials, but it does produce a signed JWT verifiable via JWKS.

• Docs: About security hardening with OpenID Connect, OpenID Connect reference

Typical values:

• Issuer: https://token.actions.githubusercontent.com
• JWKS URL: https://token.actions.githubusercontent.com/.well-known/jwks

You can use claims like repository, environment, and workflow to define identity-based access.