Documentation

Let users sign up and/or sign into your system with their IntaOps identity, this is standard OpenID Connect on top of the authorization-code flow.

1. 1. Discover the endpoints

   Read /.well-known/openid-configuration rather than hard-coding URLs. It publishes the issuer, authorization, token, userinfo, revocation and JWKS endpoints, and the scopes we support.

   curl https://infra.intaops.io/.well-known/openid-configuration

2. 2. Send the user to authorize

   Include openid in the scope. Generate a fresh nonce per sign-in and keep it, you will check it against the ID token in step 4. PKCE is required. Add patient/* scopes alongside if you belong to healthcare industry.

   Ask for only for what you need. Add profile, email or phone only if you need them. The user would see all data on the approval screen.

   https://infra.intaops.io/oauth/authorize
     ?response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://your-app.com/callback
     &scope=openid profile email        # profile/email only if you need them
     &state=<random>
     &nonce=<random, store it>
     &code_challenge=<S256 of your verifier>
     &code_challenge_method=S256

3. 3. Exchange the code

   The response carries an id_token alongside the access token, because the grant is an authorization code and carries openid.

   curl -X POST https://infra.intaops.io/oauth/token \
     -d grant_type=authorization_code \
     -d code=<code from the redirect> \
     -d redirect_uri=https://your-app.com/callback \
     -d client_id=YOUR_CLIENT_ID \
     -d client_secret=YOUR_CLIENT_SECRET \
     -d code_verifier=<your PKCE verifier>

   client_secret is required, the token endpoint authenticates the client on every grant. PKCE protects the code in transit.

4. 4. Validate the ID token

   Do not skip this step, an unvalidated ID token proves nothing. Verify the RS256 signature against /.well-known/jwks.json (match the kid), then check iss equals the issuer from discovery, aud equals your client_id, exp is in the future, and nonce matches the one you stored in step 2. Any stock OIDC library does all five for you.

5. 5. Fetch profile claims (optional)

   /oauth/userinfo returns the same sub, plus the claims your granted scopes cover — profile for the name, email for the address, phone for the number. With bare openid you get the identifier and nothing else. Absent fields are omitted rather than returned as null. email_verified and phone_number_verified reflect the person's KYC status.

   curl https://infra.intaops.io/oauth/userinfo \
     -H "Authorization: Bearer <access_token>"

6. 6. Sign out

   Revoke the refresh token, revoking a refresh token also kills the access tokens minted from the same grant, so access ends. Revoking only the access token leaves the refresh token able to mint. A 200 status code is returned for an unknown or already-revoked token by design, the endpoint cannot be used to test stolen credentials.

   curl -X POST https://infra.intaops.io/oauth/revoke \
     -d token=<refresh_token> \
     -d token_type_hint=refresh_token \
     -d client_id=YOUR_CLIENT_ID -d client_secret=YOUR_SECRET

   Our SDKs expose this as revoke(), which defaults to the refresh token for exactly this reason.