HOODIE Identity

Let people sign in to your application with their HOODIE account. A focused OpenID Connect authorization-code integration for approved applications.

Availability

The provider and a private reference integration are implemented and verified locally. Production rollout and real Google or wallet authentication remain pending; the endpoints below describe the release contract. This guide does not announce an active public login service.

Applications are approved individually. There is no public client registration. This is a limited OpenID Connect code-flow profile; it is not an OpenID-certified provider and does not implement every optional OIDC feature.

How sign-in works

No wallet transaction or gas payment is required to sign in. This does not grant the application wallet access, authorize purchases or connect financial execution.

Integrate your app

Register an approved application

• Provide the application name, homepage and exact HTTPS callback URLs to the HOODIE team. Wildcard redirects are not accepted.
• Receive a client ID and a dedicated random client secret. Keep the secret on your private backend. Never put it in browser code, public environment variables or a shared admin credential.
• Use a maintained OIDC client library with explicit ID-token signature verification enabled. The private reference integration uses openid-client.

Authorization request

Issuer

https://affiliate.hoodie.space

Flow

response_type=code · response_mode=query

Scope

openid only

PKCE

S256 required; keep the verifier private and bound to the initiating browser

State and nonce

Generate secure random values per request; validate both and consume the request once

Authentication age

Send max_age=600; verify auth_time. max_age=0 requests fresh sign-in

Callback

Your exact registered HTTPS callback, for example https://your-app.example/auth/hoodie/callback (illustrative only)

Callback and token verification

• Reject a callback that does not match the original browser, state and returned issuer. Handle cancellation without creating or linking an account.
• Exchange the code on your backend using application/x-www-form-urlencoded, HTTP Basic client authentication, the original redirect_uri and code_verifier.
• Verify the ID-token RS256 signature against the issuer's JWKS. Validate issuer, audience, nonce, expiry, issued time, authentication time and access-token hash. Pin the approved issuer and expected algorithm; do not accept endpoints supplied by browser input.
• For openid-client, enableNonRepudiationChecks explicitly enables ID-token JWS verification. Use authorizationCodeGrant with expectedState, expectedNonce, pkceCodeVerifier, idTokenExpected and maxAge.
• Create your own secure application session from the verified issuer and subject. Do not treat the ID token as a wallet permission or store tokens in browser local storage.

See the official openid-client documentation and its signature-verification option. Request an approved backend example from the HOODIE team.

Endpoints

Paths are relative to the issuer. Discover metadata and validate it against the approved contract before redirecting. Metadata and JWKS contain public information; the token exchange stays on your server.

Authorization request

10 minutes

Authorization code

90 seconds · single use

ID / access tokens

5 minutes · no refresh token

ID-token signing

RS256 · RSA key ID in kid

Supported grants

authorization_code only · confidential server applications

Data and permissions

The application receives a stable HOODIE profile UUID in sub, together with protocol claims: iss, aud, iat, exp, auth_time, nonce when requested and at_hash. UserInfo returns the same subject ID.

The subject is public within this approved-app system: the same person has the same ID across approved applications. Integrators must disclose their own use of this identifier and protect it as account data.

• No email, X, Telegram, display name, holdings or wallet address is included in this sign-in scope.
• Private keys, balances, cards, purchases and other application data stay in their existing systems.
• Consent is shown for each authorization. Silent requests return login_required or consent_required when interaction is needed.
• There are no profile, wallet or transaction scopes, refresh grants, implicit grants or dynamic client registration in this version.

Account linking

Use the verified pair (iss, sub) as the external identity key. Never merge accounts by an email address, display name or wallet supplied by the browser.

For an existing application account, start linking from its authenticated account settings. Bind the request to that account and its current session, require appropriate fresh authentication, and reject a subject already linked elsewhere.

Adding HOODIE sign-in should preserve the existing application account and its data. Add a login method to that account; do not create a replacement account or migrate its data merely because a new sign-in method is linked.

Release and operations

• Deploy matching provider and application releases with sign-in flags initially off. Verify migrations, callbacks and served versions, then enable the configured provider and check discovery/JWKS. Enable the application's sign-in flag next and complete real login/linking acceptance checks. Test with an isolated local database first.
• Use an independent secret for every approved client. The provider stores its SHA256 hash in its server-only registry. Removing a client and restarting the provider disables new authorization and exchange for it.
• Keep the dedicated private RSA signing key on the provider server. Publish only public keys. During rotation, retain retired public keys through the token lifetime, JWKS cache window and a clock margin.
• HOODIE logout invalidates outstanding codes and access tokens tied to that HOODIE session. Your app session is owned by your app; shared logout and an end_session endpoint are not implemented.
• Development accepts explicit HTTP loopback origins only. Production requires the canonical HTTPS issuer. Never disable TLS verification or allow arbitrary issuers to make integration work.

Test your integration

These acceptance checks run after coordinated activation of your actual application and private backend. A local consent demonstration does not prove real Google or wallet login. No purchase, deposit, withdrawal or gas payment is required.

If the button is absent, check your application's sign-in configuration and verify both deployed versions. Metadata must be JSON from the approved issuer. Record account continuity privately; keep authorization codes, tokens, cookies and credentials out of screenshots and reports.

Questions