TempoLife › Features › Sign in with TempoLife

Sign in with TempoLife

Authorization code with PKCE, five read-only scopes, exact redirect URI matching and user-revocable consent. The specification is published and client registration is open; the authorization endpoint is not live yet.

Specification · Register a client

The authorization server is not live. There is no /oauth/authorize, no /oauth/token and no consent screen in production today — a request to any of them returns 404. What is open is client registration: you can reserve a client id and build against the specification below, and your registration moves from pending to approved when the endpoints ship. Do not put a "Sign in with TempoLife" button in front of users yet.

What it will be for

A recipe site that wants to show a reader their own remaining calories for the day. A gym app that wants the member's sleep beside their training load. A dietitian tool that wants a client's food log with the client's explicit permission instead of a screenshot. All three want the same thing: read access to one person's data, granted by that person, scoped to what they agreed to, and revocable in one click.

That is the whole product. It is not a login system for your app — TempoLife will not be a general identity provider, and the profile scope deliberately does not include the email address, so you cannot use it to build an account for someone. It is a data-sharing consent flow with an authentication step in front.

Scopes

Ask for the least you need. A consent screen listing five scopes converts worse than one listing two, and the request will be reviewed at registration: a client asking for sleep and weight when its product is a recipe box will be asked why.

The flow, request by request

Standard OAuth 2.1 shapes. Everything below is the specification you can implement against; none of these URLs answer today.

1. Generate a PKCE pair

Before you send the user anywhere, create a high-entropy code_verifier and its SHA-256 challenge. The verifier never leaves your server; the challenge is what travels in the browser. This is what makes an intercepted authorization code useless to an attacker.

<?php
$verifier  = rtrim(strtr(base64_encode(random_bytes(64)), '+/', '-_'), '=');
$challenge = rtrim(strtr(base64_encode(hash('sha256', $verifier, true)), '+/', '-_'), '=');
$state     = bin2hex(random_bytes(16));
// Store $verifier and $state in the user's server-side session, not in a cookie
// you also read from JavaScript, and not in the URL.

2. Send the user to the authorization endpoint

GET /oauth/authorize
      ?response_type=code
      &client_id=tlc_0123456789abcdef
      &redirect_uri=https%3A%2F%2Fpartner.example%2Fcallback
      &scope=profile%20meals%3Aread
      &state=9f1c2a...
      &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
      &code_challenge_method=S256
Host: tempolife.app

code_challenge_method must be S256. The plain method will be rejected, and so will a request with no challenge at all — PKCE is mandatory for every client type, including confidential ones.

3. The user sees the consent screen

Below is what the screen will show. It is a mock-up rendered on this page for review, not a live screen — clicking nothing here does anything.

Three deliberate details in that screen. The exact redirect host is shown, because that is the single most useful anti-phishing signal a consent screen can give. Each scope is stated with what it does not include, because "access your meals" without a boundary makes people assume the worst. And "read-only" is asserted at the point of decision rather than buried in terms.

4. TempoLife redirects back with a code

HTTP/1.1 302 Found
Location: https://partner.example/callback?code=tlac_9c1f…&state=9f1c2a…

Compare state against what you stored before you do anything else. A callback with a missing or mismatched state is an attack or a bug; either way, stop. The code is single-use and expires after 60 seconds, so exchange it immediately rather than queueing it.

5. Exchange the code for tokens

POST /oauth/token HTTP/1.1
Host: tempolife.app
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(client_id:client_secret)>

grant_type=authorization_code
&code=tlac_9c1f…
&redirect_uri=https%3A%2F%2Fpartner.example%2Fcallback
&code_verifier=<the verifier from step 1>

{
  "access_token": "tlat_…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tlrt_…",
  "scope": "profile meals:read"
}

The redirect_uri is repeated here and must match the one from step 2 exactly, as an anchored string comparison. Note the returned scope: a user may untick a scope on the consent screen, so what you get back can be narrower than what you asked for. Read that field rather than assuming.

6. Call the API

GET /oauth/userinfo HTTP/1.1
Host: tempolife.app
Authorization: Bearer tlat_…

Access tokens last 60 minutes. Refresh with grant_type=refresh_token; refresh tokens rotate on use, so store the new one and discard the old. If a refresh is ever replayed with an already-used token, the whole grant will be revoked — that is the standard defence against a stolen refresh token, and it means a buggy client that retries a refresh will log its users out. Serialise your refreshes.

Revocation

Two directions, and both will work.

• The user revokes. From their TempoLife account settings, per client. The refresh token dies immediately; an access token already in flight remains valid until it expires, which is why an hour is the ceiling rather than a day. Your client should treat a 401 as "consent withdrawn" and stop retrying rather than looping.
• The client revokes. POST /oauth/revoke with the token, per RFC 7009. Call it when a user disconnects on your side. Leaving a live grant behind after someone has removed your integration is the kind of thing that ends a partnership.

Consent is recorded as one row per client per user, with a granted timestamp and a revoked timestamp. Revoking sets the timestamp rather than deleting the row, so both sides can answer "when did this stop" later. Deleting a TempoLife account removes the user's consents entirely.

What a client must satisfy

What ships when the endpoints go live

So that nobody has to guess what "live" will mean: an authorization endpoint that renders the consent screen for a signed-in user, a token endpoint implementing the authorization code and refresh token grants, a revocation endpoint, a userinfo endpoint scoped to profile, and per-scope read endpoints for meals, steps, sleep and weight. Alongside them, a discovery document at /.well-known/oauth-authorization-server so libraries can configure themselves, and a consent management screen in account settings. Registered clients move from pending to approved as part of that release; nothing you register now is lost.

Until then, this page is a specification and a queue. If you need TempoLife data before that, the public food API is live today and needs no account at all — it just does not carry anyone's personal log.

Frequently asked questions

Source: TempoLife platform specification, published for partner review · checked 2026-09-02

Register a clientThe live food API