Human Pass is a standard OpenID Connect provider, so any certified library works: Auth.js, Spring Security, ASP.NET Core, Authlib, Django and Rails libraries, and others. Give it these settings.
Settings
| Setting | Value |
|---|---|
| Issuer | https://id.humanpass.co (sandbox: https://id.sandbox.humanpass.co) |
| Discovery | https://id.humanpass.co/.well-known/openid-configuration |
| Flow | Authorization code (response_type=code) |
| PKCE | Required, S256 |
| Scopes | openid personhood, plus any optional attributes |
| Client authentication | client_secret_basic (server-side clients), private_key_jwt, or none (public clients, PKCE only) |
| ID token signature | ES256 |
| Subject type | pairwise: a different sub per project |
| Refresh tokens | None: start your own session after sign-in |
Endpoints
Discovery gives you all of these; you shouldn't need to type them.
| Endpoint | Address |
|---|---|
| Authorization | https://id.humanpass.co/oauth/authorize |
| Token | https://id.humanpass.co/oauth/token |
| UserInfo | https://id.humanpass.co/userinfo |
| Keys (JWKS) | https://id.humanpass.co/jwks |
| Token revocation | https://id.humanpass.co/oauth/revoke |
| Status API (Human Pass) | https://id.humanpass.co/v1/subjects/status |
Common pitfalls
- ES256. Some libraries assume RS256 unless told otherwise; Human Pass signs ID tokens with ES256 (in its JWKS).
- No profile or email. Don't map users by email or name: there aren't any. Use
sub. - PKCE. Requests without a
code_challengeare refused, even from server-side clients. - Exact redirect URIs. The redirect URI must match one registered on the client exactly: scheme, host, port and path.
- Claims in the ID token.
verified_humanand any attributes are in the ID token itself; calling UserInfo isn't needed.